你的容器应用如何被外界访问？
故障定位思路
关于Service Ingress，最值得先弄清楚的是配置边界和排错顺序。想象你刚刚把一个 Web 应用打包成 Docker 镜像，部署到了 Kubernetes 集群。Pod 在集群内部跑起来了，但问题来了——用户怎么访问它？
Kubernetes 的 Pod 是“临时”的，IP 会随重启变化；而且 Pod 运行在隔离的容器网络中，外界的流量进不来。这时就需要两个“翻译官”来搭桥：Service 和 Ingress。而在云上（比如阿里云、腾讯云、AWS），这两个组件往往和 VPC 负载均衡器 捆绑工作。理解它们之间如何“贴合”，是避免性能踩坑的关键。
相关阅读：此处可内链到“Service Ingress常见问题”专题。
补充参考：此处可内链到“Service Ingress故障排查实例”。
Service：最基础的“内部名片”与Service Ingress
Kubernetes Service 的核心任务很简单：为一组 Pod 提供一个稳定的访问入口。它像一个“服务员”，告诉你“这个服务叫 my-app，你访问这个虚拟 IP 就行了，Pod 的变动我来处理”。
Service 有几种类型，最常见的是 ClusterIP（仅集群内可访问）和 NodePort（通过节点 IP + 端口暴露）。对于云原生场景，LoadBalancer 类型可以直接触发云厂商创建负载均衡器。
- ClusterIP：适合内部调用，比如后端 API 给前端微服务。
- NodePort：在集群每个节点上开一个端口，流量从节点端口转发到 Pod。但节点 IP 会被 NAT 转换，源 IP 丢失。
- LoadBalancer：云厂商自动创建一个云负载均衡器，把公网流量引到集群内部。这是最“开箱即用”的方式。
性能注意点：Service 的负载均衡模式
Service 默认使用 iptables 或 IPVS 做流量转发。如果是跨节点转发，流量会经过宿主机上的 kube-proxy 进程，增加一次 NAT 开销。当 Pod 规模很大时，iptables 规则数膨胀，更新规则时会消耗 CPU。
因此，对于高性能场景，建议启用 IPVS 模式（哈希表查找，时间复杂度 O(1)），或者直接让云负载均衡器直连 Pod（绕过 kube-proxy）。多数云厂商的 VPC 负载均衡器支持将 Pod IP 注册为后端，这就是“原生容器网络”的优势。
关联教程：此处可内链到“Service Ingress部署与验证”内容。
Ingress：七层路由的“门卫”
Service 只能做四层转发（TCP/UDP）。当你需要根据域名、路径路由到不同服务（比如 /api 去后端，/static 去静态资源），或者在相同域名下实现 HTTPS 终结 —— 你就需要 Ingress。
Ingress 不是 Kubernetes 内部组件，而是一类 API 对象，需要部署一个 Ingress Controller（比如 Nginx Ingress Controller、Traefik、ALB Ingress Controller）才能工作。Ingress Controller 像一个智能路由网关，它读取 Ingress 规则，动态配置自己的代理规则。
Ingress 与 VPC 负载均衡器的关系
一个常见的架构是：
- 云厂商的 VPC 负载均衡器（如阿里云 SLB、AWS ALB）接受公网流量。
- 负载均衡器将流量转发到集群内 Ingress Controller 的 NodePort 或 LoadBalancer Service。
- Ingress Controller 根据域名/路径，将请求分发到对应的 Service，再转发到 Pod。
这意味着流量经过了两层负载均衡：云负载均衡器 → Ingress Controller → Service → Pod。每一层都增加延迟和资源消耗。
性能贴合：让两层变成“一层半”
所谓的“性能贴合”，就是尽量让云负载均衡器直接感知 Pod，减少中间跳数。具体做法有：
1. 使用 Local 模式绕过 kube-proxy
如果 Service 设置了 externalTrafficPolicy: Local，云负载均衡器只会把流量转发到本地有 Pod 的节点。这样避免了跨节点 NAT 和 SNAT，保留源 IP。缺点是负载不均（某节点无 Pod 则流量丢弃）。配合 节点亲和性 或 Pod 反亲和 可以缓解。
2. 直接使用云厂商的 CNI 插件
很多云厂商提供容器网络插件（如阿里云 Terway、AWS VPC CNI），让 Pod 直接获取 VPC 内的 IP，而不是通过 overlay 网络。这样 Pod 就和云资源（负载均衡器、RDS）处于同一个二层网络，负载均衡器可以直接向后端 Pod IP 发流量。
3. 使用 ALB Ingress Controller（或其他云原生 Ingress 方案）
以 AWS ALB Ingress Controller 为例，它直接将 ALB 配置为 Ingress 的后端，流量从 ALB 到 Pod 是直连的（通过 ENI 挂载），不再经过 NodePort。延迟降低 30%-50%。类似地，阿里云的 ALB Ingress 也支持直接挂载 Pod ENI。
进阶阅读：此处可内链到“Service Ingress性能优化”指南。
实践中的常见坑与优化建议与Service Ingress
坑1：超大规模下的 iptables 性能
当 Pod 数量超过 1000 个，iptables 规则可能达到数万条，更新一条规则就会占用 100ms 级 CPU。此时应该使用 IPVS 或直接让负载均衡器直连 Pod。如果使用云厂商 VPC 网络，建议开启 Direct LVS 模式。
坑2：健康检查超时导致 Pod 被“踢出”
云负载均衡器会定期对后端 Pod 发健康检查。如果你的 Pod 启动慢或内存吃紧，可能会被标记为不健康，导致流量断流。调整 Pod 的 startupProbe 和 livenessProbe 的阈值，并与负载均衡器的健康检查参数对齐。
坑3：Ingress Controller 成为瓶颈
如果流量都经过单一的 Ingress Controller Pod，这个 Pod 的 CPU/内存会成为瓶颈。解决方案：水平扩容 Ingress Controller 副本数，并利用 podAntiAffinity 分散到不同节点。云原生场景下，也可以直接用云负载均衡器的七层能力（如 AWS ALB）代替 Ingress Controller。
总结：选择“贴合”方案的三原则
故障定位思路
- 少跳数：让云负载均衡器直接向后端 Pod 转发，避免 kube-proxy 和中间代理。
- 无状态：Ingress Controller 等组件尽量保持无状态，方便水平伸缩。
- 监控先行：无论哪种方案，必须监控每一跳的延迟和错误率。使用 metrics-server、Kiali 或云厂商的监控服务。
对于中小规模业务，直接用 Service LoadBalancer + 云负载均衡器已经足够。对于大型互联网应用，需要深度利用云厂商的容器网络能力，让 Service 和 Ingress 成为“轻量级”的路由规则，而不是流量处理瓶颈。理解这些概念，你就能在网络层面做出更优的架构决策。真正做好Service Ingress，靠的不是参数堆砌，而是持续验证。
延伸阅读