type
status
date
slug
summary
tags
category
icon
password
Kubernetes 的“路由”话题经常让人困惑：Service、NodePort、Ingress、Gateway 这些名词听起来都像“把请求转发到应用”，但它们解决的问题并不相同。更现实的问题是：当看到一个外部域名（例如
https://<service>.<dc>.example.internal）时，如何把它和集群里的对象一一对应起来，知道流量到底走了哪条路径？这篇文章尝试把概念讲清楚，并把它们组织成一个可复用的心智模型：从里到外分层。读完后，应该能够回答三类问题：
- Service 到底解决什么问题？为什么要有
ClusterIP/NodePort/LoadBalancer？
- Ingress 和 Gateway 为什么“差不多”，又为什么要分成两套？
- 在云上时，K8s 如何与云负载均衡器关联，域名又是如何“被暴露出来”的？
一、全局视角：从外到内的三层结构
把 Kubernetes 路由相关对象分成三层，会更容易理解：
- 计算层：Pod
- 应用真正运行的地方，监听端口（如 3000）。
- 服务发现层：Service
- 把“一堆会变的 Pod”抽象成“一个稳定的后端服务入口”。
- 入口与治理层：Ingress / Gateway
- 把外部 HTTP(S) 流量接进集群，并按域名/路径路由到不同 Service，同时承载 TLS、访问控制、插件等治理能力。
关键句：
- Service 解决“后端不稳定”
- Ingress/Gateway 解决“入口路由与治理”
二、Pod：应用所在之处，但不适合作为稳定入口
Pod 是 Kubernetes 调度的最小单位。多数情况下，一个 Pod 包含一个应用容器（也可能有 sidecar），容器里运行进程并监听端口。
Pod 的关键特性：
- 生命周期短、可替换：重启、扩缩容、发布都会产生新的 Pod
- IP 不稳定：Pod 重建后 IP 会变化
因此，Pod 适合作为“流量最终落点”，不适合直接作为“稳定入口”。这也是 Service 存在的第一动机。
三、Service：把一组 Pod 变成一个稳定的“服务”
Service 的核心价值是稳定性：无论后端 Pod 怎么变，Service 仍然提供一个稳定入口（稳定的 DNS 名称与虚拟 IP），并把流量负载均衡到后端 Pod。
3.1 Service 的工作方式（直觉版）
- Service 通过 selector 选中一组 Pod（或指向一组 Endpoints/EndpointSlice）
- K8s 维护后端列表
- 访问 Service 时，流量被分发到某一个后端 Pod
3.2 Service 的常见类型
1) ClusterIP（默认）
- 只能在集群内部访问
- 最常见：微服务之间互相调用、内部依赖（Redis、内部 API 等）
适用场景：服务对服务的内部通信。
2) NodePort
- 在每个 Node 上开放一个端口（通常在 30000–32767 范围）
- 外部可访问
NodeIP:NodePort→ 进入该 Service → 转发到后端 Pod
定位更像“低门槛暴露方式”或“给外部 LB 一个固定入口”。不足：
- 端口范围有限
- 治理能力弱
- 生产环境通常不会把 NodePort 当最终对外入口
3) LoadBalancer
- 云环境下会自动创建一个云负载均衡器
- 得到一个外部地址（例如
<cloud-lb-dns>）
适用场景：
- 单个服务要直接对外（且不需要复杂的 host/path 路由）
- 或者给“入口组件”（ingress controller / 网关 proxy）配一个对外 LB
四、Ingress：描述 HTTP(S) 路由规则的资源
Ingress 可以理解成“HTTP(S) 路由规则的标准接口”，通常描述：
- 哪些域名（Host）
- 哪些路径（Path）
- 转发到哪个 Service
要点：
- Ingress 资源本身不负责转发
- 真正负责转发的是 Ingress Controller（例如 Nginx Ingress Controller，或云厂商的 LB Controller）
Ingress 的优势是模型简单；劣势是很多高级能力依赖 controller 的私有扩展（例如 annotation），标准化与协作边界相对一般。
五、Gateway API：Ingress 的“下一代入口标准”
Gateway API 的核心价值不是“Ingress 不能用”，而是让入口体系更标准化、更可治理、更适合多团队协作。
它将入口模型拆分为：
- GatewayClass：网关实现提供的能力类型
- Gateway：入口实例（监听端口/hostname/TLS/允许哪些 namespace 挂载路由）
- HTTPRoute：路由规则（host/path → backend Service）
理解方式：
- Ingress：入口与路由往往揉在一个对象里
- Gateway API：入口（Gateway）与路由（HTTPRoute）分开，更清晰
六、网关（Gateway 实现）：入口能力的落地者
“网关”可以理解为集群入口层的反向代理/API 网关实现，常见职责包括：
- 作为入口代理接收外部流量
- 按路由规则转发到后端 Service
- 提供治理能力（鉴权、限流、IP 白名单、日志、观测等）
在 Gateway API 模式下：
- Gateway/HTTPRoute 描述规则与绑定关系
- 网关 controller 负责把规则落实成实际转发行为
七、云上负载均衡器：为什么会出现 “LB”
云上对外暴露通常会经过云负载均衡器。常见机制是：
- 集群里运行一个 controller
- controller 监听 K8s 资源变化（例如 Ingress）
- controller 调用云厂商 API 创建/更新真实的 LB（Listener、TargetGroup、健康检查等）
这解释了一个常见现象：外部出现一个
<cloud-lb-dns> 并不是手工创建，而是由 K8s 声明式配置驱动的自动化结果。八、把示例域名串起来：从 DNS 到 Pod 的完整链路
以
https://<service>.<dc>.example.internal 为例，一条典型链路是：- DNS
- 域名解析到对外入口地址（例如
<cloud-lb-dns>）
- 云负载均衡器（LB）
- 接收 443，转发到集群入口网关/入口组件
- 入口与路由（Ingress 或 Gateway/HTTPRoute）
- 按 host/path 匹配，选择后端 Service
- Service
- 稳定入口，负载均衡到后端 Pod
- Pod
- 处理请求并返回响应
九、速记：如何区分这些名词
- Service：稳定的后端入口 + 负载均衡到 Pod（解决“后端不稳定”）
- ClusterIP：Service 默认形态，集群内访问
- NodePort：Service 暴露方式之一，Node 上开端口
- LoadBalancer：Service 暴露方式之一，云上创建 LB
- Ingress：HTTP(S) 入口路由规则（需要 ingress controller）
- Gateway/HTTPRoute：更结构化的入口与路由标准（需要 gateway controller）
- 云负载均衡器（LB）：云侧入口（常由 controller 根据 K8s 资源创建/维护）
附录：一套从域名追到 Pod 的排障路径（kubectl 实操版）
排查路由问题时，建议采用固定路径：从外到内。每一层只回答一个问题：这一层是否工作、下一跳是谁、证据是什么。
A. 确认 kubectl 指向正确集群
B. Gateway API 场景：先看 Gateway 是否 Ready、监听是否覆盖域名
关注点：
spec.listeners[].hostname是否覆盖目标域名/通配符
status.conditions是否Ready=True
C. Gateway API 场景：再看 HTTPRoute 是否被接受、后端引用是否解析成功
关注点：
spec.hostnames是否命中目标域名（如<service>.<dc>.example.internal）
spec.parentRefs是否绑定正确 Gateway
spec.rules.backendRefs指向哪个 Service/端口
status.parents[].conditions是否Accepted=True、ResolvedRefs=True
当 route 名称未知时，可按域名粗搜：
D. Service 层：Service 是否存在、端口是否正确、是否真的选到了后端
继续确认 endpoints：
如果 endpoints 为空，优先检查：
- Pod label 是否匹配 Service selector
- readiness 是否通过
targetPort是否正确
E. Pod 层：Pod 是否 Ready、事件与日志是否暴露根因
F. Ingress 场景：Ingress 是否生成外部地址、Events 是否提示失败原因
关注点：
- 是否存在外部 Address（常见为
<cloud-lb-dns>）
Events是否有权限、子网、证书、规则冲突等错误提示
G. 用错误码当“指路牌”
- 连接超时：优先检查入口层与网络边界（LB/Ingress/Gateway、网络策略、安全组）
- 404：优先检查路由未命中（host/path、绑定关系）
- 502/503：优先检查后端不可达（Service endpoints 为空、Pod 不 Ready、端口映射错误）
- Author:Ximou Zhao
- URL:https://ximouzhao.com/article/1d54b0ac-588b-80d3-a571-eefc9092757b
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
