云原生 AI 平台网络规划：东西向和南北向流量分开治理

云原生 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 模式或 eBPFCilium模式。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 白名单模式起步先收敛东西向的安全边界——即便暂时合并网络平面也要把服务间的访问控制做到位。然后再根据实际的性能数据和集群规模判断是否需要分离平面。不要用架构设计去解决还不存在的性能问题。