云原生 AI 平台网络规划：东西向和南北向流量分开治理
一、合并治理的隐患：为什么推理延迟抖动总指向网络层
AI 推理平台的流量模式与传统微服务有本质区别。传统微服务的南北向流量（客户端到服务端）占主导，东西向流量（服务间调用）相对有限。但 AI 平台的情况不同：一次典型的 RAG 请求可能涉及 API 网关到 Embedding 服务、Embedding 服务到向量数据库、向量结果传到 Reranker 服务、最后 Reranker 的结果传给 LLM——这一串调用全是东西向流量。如果南北向和东西向流量在同一个网络平面里混跑，高并发场景下推理延迟会出现难以解释的抖动。
实测数据可以直观地说明这个问题。在一个共享网络平面的场景下，当南北向流量达到峰值（QPS 超过 5000），东西向的服务间调用 P99 延迟从 2ms 飙升至 20ms 以上。排查发现根因不在应用层，而在网络层——Kubernetes 的 kube-proxy iptables 规则数量达到万级别，南北向的大量连接占用了 conntrack 表条目不释放，导致东西向的新建连接在 conntrack 查找时排队等待。
基础设施不需要漂亮话。网络层的脏活如果不在架构设计阶段分清楚，上线后排查成本是开发成本的数倍。
二、平面分离设计：南北向入口 + 东西向服务网格
网络的平面分离意味着南北向流量走入口网关的独立网络路径，东西向流量走服务网格的内部网络路径，两条路径在物理或逻辑上隔离，互不干扰。
南北向平面负责处理客户端到平台入口的流量。入口处部署 Envoy Gateway 做 TLS 终止、认证卸载、全局限流和请求路由。南北向的关键网络决策是：在入口层就完成所有与客户端相关的处理，一旦请求进入集群内部，后续所有流量都在东西向平面上流转，不再经过南北向的限流和认证层。
东西向平面可以选择 Istio Sidecar 模式或 eBPF（Cilium）模式。Istio 的优势在于丰富的 L7 治理能力（熔断、重试、流量镜像），但 Sidecar 本身消耗额外的 CPU 和内存。对于 GPU 推理节点来说，Sidecar 占用的资源会挤占模型的可用显存或内存——T4 节点的 16G 显存在加载 7B 模型后已经所剩无几，不可能再让一个 Envoy Sidecar 消耗 200MB 内存。因此，对于推理节点，我们选择了 Cilium 的 eBPF 方案做东西向网络，它运行在内核层，不占用额外的用户空间资源。
三、关键技术实现：CNI 选型与服务间零信任
东西向网络平面的核心基础是 CNI（容器网络接口）的选择。对于 AI 推理平台，CNI 的选型标准与通用 Kubernetes 集群有所不同：吞吐量优先于延迟。推理服务之间的数据交换通常是大块 Tensor 数据（Embedding 向量返回上千维的浮点数组），每个请求的单向数据量在 50KB-500KB 之间，此时 CNI 的包转发效率和 MTU 配置比路由延迟更重要。
Cilium 的 eBPF 数据路径绕过了 kube-proxy 的 iptables 规则链，数据包在内核中直接完成转发，避免了 conntrack 表的瓶颈。实际测试中，在 10Gbps 网络环境下，Cilium eBPF 模式下服务间通信吞吐达到 9.2Gbps，而 kube-proxy iptables 模式下仅 3.8Gbps——差距主要来自 iptables 规则链的 O(n) 遍历开销。
服务间通信的安全策略同样重要。推理平台内部的服务间调用不应该默认信任——一个被攻破的 Embedding 服务不应该能够随意调用 LLM 推理服务或直接访问对象存储。我们通过 Cilium NetworkPolicy 做了严格的东西向访问控制：每个服务只被允许访问其声明的下游依赖，其他 Pod 的入站流量默认拒绝。
# 推理服务的网络策略——默认拒绝 + 白名单放行 apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: llm-inference-policy namespace: ai-inference spec: endpointSelector: matchLabels: app: llm-inference ingress: # 仅允许 API 网关和 Reranker 服务调用 LLM 推理 - fromEndpoints: - matchLabels: app: api-gateway - matchLabels: app: reranker-service toPorts: - ports: - port: "8000" protocol: TCP egress: # 推理服务只能访问 Redis 缓存和监控上报 - toEndpoints: - matchLabels: app: redis-cache toPorts: - ports: - port: "6379" protocol: TCP - toEndpoints: - matchLabels: app: prometheus-pushgateway toPorts: - ports: - port: "9091" protocol: TCP四、分离的代价：运维复杂度与跨平面通信
平面分离增加了运维复杂度。首先需要维护两套网络策略——南北向的入口网关配置（Envoy 的路由、限流、认证规则）和东西向的服务网格配置（NetworkPolicy、mTLS 证书管理），两套配置的变更流程是独立的，容易出现"南北向放行但东西向阻断"这类策略不一致的问题。必须建立统一的网络策略审计机制，定期对比两套策略的一致性。
其次是跨平面通信的延迟。在某些场景下，东西向服务需要主动发起南北向的出站请求——比如推理服务需要下载新的模型权重文件到对象存储。这类流量需要穿透网络边界，增加了配置复杂度和额外的跳转延迟。建议为模型权重下载配置专用的出站网关通道，不混入推理流量的网络路径。
平面分离的禁用场景：当集群规模较小（少于 20 个服务 Pod、QPS 低于 1000）时，kube-proxy iptables 模式的性能瓶颈不会出现，平面分离带来的额外运维成本远大于收益。不要为了架构完整性而过度设计。
五、总结
网络平面分离的核心收益：南北向和东西向流量互不干扰，推理链路的 P99 延迟保持稳定，不受外部流量波动影响。技术选型上，入口层使用 Envoy Gateway 处理南北向流量，服务间使用 Cilium eBPF 处理东西向流量。
落地建议：从 NetworkPolicy 白名单模式起步，先收敛东西向的安全边界——即便暂时合并网络平面，也要把服务间的访问控制做到位。然后再根据实际的性能数据和集群规模判断是否需要分离平面。不要用架构设计去解决还不存在的性能问题。