Ingress、Service 和集群网络链路怎么串起来看

很多人学 Kubernetes 网络时，脑子里会堆一堆名词：

• Ingress
• Service
• ClusterIP
• NodePort
• Pod IP
• CNI

但一到线上排障，还是会问：

“一个公网请求到底是怎么打到 Pod 上的？”

如果这条链路没有在脑中串起来，后面排查 404、502、超时、只在某个节点失败这类问题会非常痛苦。

先说结论

• 一个外部请求通常会经历：DNS / LB -> Ingress Controller -> Service -> Endpoint -> Pod
• Ingress 负责七层路由，Service 负责稳定服务发现和转发抽象，Pod 才是最终处理请求的实例
• 线上排障一定要按链路分层查，不要一上来只盯 Pod
• 大部分 404、502、超时问题，本质上都卡在这条链路某一层的映射不对或健康状态不对

先把一条请求路径串起来

如果你访问 api.example.com/order/create，在典型 K8s 集群里，一条请求大概会这么走：

1. 域名解析到外部负载均衡或入口地址
2. 流量进入 Ingress Controller
3. Ingress 根据 host / path 规则匹配到某个 Service
4. Service 根据 selector 找到后端 Endpoint
5. 请求被转发到某个 Pod IP
6. Pod 内业务进程真正处理请求

你可以把这条链理解成：

• Ingress 决定“去哪个服务”
• Service 决定“去这组 Pod 中的哪一个”
• Pod 决定“是否真能处理成功”

Ingress 在解决什么

Ingress 主要负责七层入口治理：

• 域名路由
• 路径路由
• TLS 证书
• 重写、转发规则

它本身不是数据面实现，真正执行这些能力的是 Ingress Controller，例如 Nginx Ingress。

所以写了 Ingress 规则，不代表就自动生效。
还要看对应的 controller 是否正常接管。

Service 在解决什么

Service 的核心价值是给一组 Pod 一个稳定的访问抽象。

因为 Pod 会重建、IP 会变化，调用方不可能永远记住某个 Pod IP。
Service 通过 selector 和 Endpoint 机制，把“Pod 在变”这件事屏蔽掉。

常见的几种类型：

• ClusterIP: 集群内访问
• NodePort: 通过节点端口暴露
• LoadBalancer: 云环境下申请外部负载均衡

很多 Ingress 最终也是把流量转给 ClusterIP Service。

Endpoint 为什么常常是排障关键

Service 只是一个抽象名字，真正后面有没有 Pod，要看 Endpoint。

如果出现：

• Service 在
• Pod 也在
• 但请求还是打不过去

很常见的一种情况就是：

• selector 配错
• readiness 没通过
• Endpoint 为空

这时问题不在 Ingress，也不在 DNS，而在 Service 根本没有后端。

一条排障思路应该怎么走

1. 先看入口有没有进来

确认 DNS、外部 LB、Ingress Controller 是否正常。

2. 再看 Ingress 规则有没有匹配

重点看：

• host
• path
• pathType
• rewrite
• backend service 名字和端口

3. 再看 Service 是否有后端

确认：

• selector 是否正确
• Endpoint 是否存在

4. 最后看 Pod 是否真能处理

包括：

• 进程端口是否监听
• readiness / liveness 是否正常
• 应用内部是否报错

几个高频故障现象怎么定位

1. 404

先看是 Ingress 返回的 404，还是应用返回的 404。

前者多半是：

• host/path 没匹配上
• rewrite 规则不对

后者多半说明流量已经到应用了，只是应用路由本身没命中。

2. 502 / 503

常见于：

• Ingress 找到 Service，但 Service 没有可用 Endpoint
• Pod 启动了，但 readiness 没通过
• 应用端口和 Service targetPort 不一致

3. 超时

常见要分几层看：

• 入口到 Ingress 慢
• Ingress 到 Service / Pod 慢
• Pod 内部依赖 DB / Redis / RPC 慢

不要看到超时就只怪网络。

为什么只看 Pod 常常会误判

因为 Pod Running 不等于流量一定能打通。

可能出现：

• Pod 正常运行，但 readiness 没过，没进 Endpoint
• Pod 端口和 Service targetPort 配错
• Ingress 指向了错误的 Service

所以 Kubernetes 网络问题往往是“映射链路问题”，不是“单个实例挂了”。

一个更顺手的心智图

你可以这样记：

• 域名层: 请求能不能到集群入口
• 路由层: Ingress 有没有把请求导向对的 Service
• 服务层: Service 有没有选中正确 Pod
• 实例层: Pod 是否真可用

排障时就沿这四层一层层缩小范围。

总结

Ingress、Service 和集群网络链路最重要的，不是记住名词，而是把请求路径真正串起来：

外部入口 -> Ingress -> Service -> Endpoint -> Pod

一旦这条链在脑子里清楚了，Kubernetes 大多数网络类问题都会从“很玄学”变成“可定位的分层问题”。