南北向与东西向流量

前面几章其实一直在围着两类流量打转，只是没点破。这一章把概念拎出来，让你以后看架构图不再晕。

31-1 两个方向，一张图就懂

想像集群是个园区：

• 南北向流量（North-South）：园区外面和园区里面之间的流量。也就是客户端浏览器、手机 App、外部系统，访问你集群里的服务。它是”从外到内、从内到外”的纵向流量。
• 东西向流量（East-West）：园区内部，服务和服务之间互调的流量。订单服务调库存、库存调用户，全在一个集群里横向流动。

打个比方。南北向是”顾客进门点单”，东西向是”后厨各档口之间传菜”。两者都很重要，但管法完全不同。

31-2 南北向：靠入口层承接

外部流量要进集群，得有个”大门”。承载南北向的组件有两层：

1. Service 类型：NodePort 或 LoadBalancer 把服务直接露到集群外（四层 IP+端口）。
2. Ingress / Gateway：七层入口，按域名、路径、TLS 把流量导进内部 Service。

前面第 28 章讲的 Ingress，就是典型的南北向入口。它站在集群边缘，把外部 HTTP 请求翻译成对内部 Service 的调用。

31-3 东西向：靠 Service 和 CNI 承接

集群内部，一个 Pod 想调另一个 Pod，走的是东西向。这条链路由几段拼成：

• Service（虚拟 IP）：调用方连稳定的 Service 地址，不用管后端 Pod 怎么变。
• kube-proxy / 数据面：把虚拟 IP 转发到真实 Pod IP。
• CNI 网络：保证 Pod 之间底层能通。
• NetworkPolicy：决定 Pod 之间”允许不允许通”（上一章讲的）。

所以东西向的默认状态是全通，安全靠 NetworkPolicy 去收紧。微服务越多，东西向流量越密，治理难度也越高。

31-4 南北向和东西向的治理痛点不同

方向不同，要解决的问题也不一样：

• 南北向的痛点：怎么对外暴露、怎么做域名和路径路由、怎么终结 TLS、怎么做限流和认证。
• 东西向的痛点：服务怎么互相发现、调用失败怎么重试、流量怎么灰度、服务间通信怎么加密和鉴权。

31-5 Ingress 的局限与 Gateway API

Ingress API 在 v1.19 就 GA 了，但能力有限：只支持 HTTP/HTTPS、负载均衡只暴露少量参数、缺少细粒度路由和可移植性。官方在 v1.36 明确建议新项目优先考虑 Gateway API（基于 gateway.networking.k8s.io）。

Gateway API 把”谁管基础设施”和”谁管路由”拆开：集群管理员配 Gateway，应用开发者配 HTTPRoute。角色更清晰，能力也更强。不过 Ingress 仍稳定可用，老集群继续用没问题。

31-6 服务网格：专治东西向

当东西向流量变得复杂——几十上百个服务互相调，你开始想要：调用链追踪、自动重试、熔断、按版本灰度、mTLS 加密——这些超出 NetworkPolicy 和 Service 的范围。

这时上服务网格（Service Mesh），典型如 Istio、Linkerd。它在每个 Pod 旁边注入一个”边车（sidecar）代理”，接管所有进出 Pod 的流量，从而实现细粒度的东西向治理。

31-7 一张对照表收尾

维度	南北向	东西向
流量方向	外部 ↔ 集群	Pod ↔ Pod
典型组件	Ingress / Gateway / LoadBalancer	Service / kube-proxy / CNI
关注点	域名、路由、TLS、入口负载	服务发现、重试、灰度、加密
安全手段	认证、WAF、限流	NetworkPolicy、服务网格 mTLS
七层治理	Ingress 规则、Gateway API	服务网格

31-8 本部分小结

到这里，第 5 部分（服务与网络）全部讲完。我们沿着流量走了一遍：

• Service 用虚拟 IP 兜住易变的 Pod 集合。
• ClusterIP/NodePort/LoadBalancer 决定暴露范围。
• CoreDNS 让 Pod 用名字而非 IP 互相发现。
• Ingress 在边缘做七层路由，承接南北向。
• CNI 实现底层网络模型，NetworkPolicy 在上面收紧东西向。
• 最后用南北向/东西向这个框架，把前面所有组件串成一张图。

理解南北向和东西向，是看懂任何 Kubernetes 网络架构图的前提。带着这个视角，你再去读 Ingress、Gateway、服务网格的文档，会顺畅很多。