2. 数据传输基础：控制面与数据面的通信模型、南北向与东西向流量特征
在容器运行时治理体系中，理解控制面与数据面的通信模型是优化数据传输的前提。本章从通信模型、流量特征两个维度，拆解南北向与东西向流量的核心差异，并给出可落地的治理策略。
2.1 控制面与数据面的通信模型
容器运行时治理控制面通常由 API Server、Scheduler、Controller Manager 等组件构成，数据面则由 kubelet、容器运行时（如 containerd、CRI-O）、网络代理（如 kube-proxy、CNI 插件） 组成。两者之间的通信模型可归纳为以下三种模式：
| 通信模式 | 方向 | 协议/载体 | 典型场景 | 延迟敏感度 |
|---|---|---|---|---|
| 控制面→数据面 | 下行指令 | gRPC / HTTP/2 | Pod 创建、配置下发、健康检查 | 中（秒级可接受） |
| 数据面→控制面 | 上行状态 | gRPC / Webhook | 节点心跳、Pod 状态上报、事件推送 | 低（毫秒级要求） |
| 数据面↔数据面 | 对等通信 | Overlay / Underlay | 容器间网络 I/O、存储挂载 | 高（微秒级要求） |
治理要点：控制面与数据面之间的通信应优先使用 gRPC 双向流，减少轮询开销；数据面之间的通信应避免经过控制面代理，直接通过 CNI 或 Service Mesh 数据面完成。
2.2 南北向流量特征
南北向流量指从集群外部进入或离开集群的流量，通常经过 Ingress Controller、Load Balancer、NodePort 或 Gateway API 等入口组件。其核心特征如下：
- 入口集中：所有外部请求汇聚到少数入口节点，容易形成瓶颈。
- 协议多样：HTTP/HTTPS、gRPC、WebSocket、TCP/UDP 混合存在。
- 安全要求高：TLS 终止、WAF 过滤、认证鉴权通常在此层完成。
- 延迟敏感：用户侧体验直接受入口延迟影响，通常要求 P99 < 200ms。
优化方向：南北向流量治理应聚焦于 连接复用（HTTP/2 多路复用）、TLS 会话缓存、入口节点水平扩展 以及 智能路由（基于路径、Header、Cookie 的灰度发布）。
2.3 东西向流量特征
东西向流量指集群内部 Pod 与 Pod、Service 与 Service 之间的通信，是容器运行时治理的核心战场。其典型特征包括：
| 特征维度 | 描述 | 治理挑战 |
|---|---|---|
| 流量密度 | 微服务间频繁 RPC 调用，每秒可达数万至数百万次 | 连接数爆炸、CPU 上下文切换 |
| 拓扑动态 | Pod 频繁创建/销毁，IP 地址不断变化 | 服务发现延迟、连接失效 |
| 协议单一化 | gRPC、HTTP/2 成为主流，TCP 长连接占比高 | 连接池管理、负载均衡策略 |
| 延迟敏感 | 微服务调用链中，单跳延迟要求 < 1ms | 内核网络栈开销、eBPF 加速 |
常见误区：东西向流量治理中，不要盲目使用全链路加密（mTLS）覆盖所有内部通信。对于非敏感数据，建议采用 明文 + 网络隔离 策略，避免 TLS 握手带来的额外延迟和 CPU 开销。
2.4 通信模型与流量特征的关系图
下图展示了控制面与数据面之间的通信模型，以及南北向、东西向流量的典型路径：
2.5 流量特征对比总结
下表从多个维度对比南北向与东西向流量的差异，帮助治理团队制定差异化的优化策略：
| 对比维度 | 南北向流量 | 东西向流量 |
|---|---|---|
| 流量来源 | 集群外部用户/系统 | 集群内部 Pod/Service |
| 入口组件 | Ingress Controller、LB、Gateway | Service Mesh Sidecar、CNI |
| 协议多样性 | 高（HTTP/HTTPS/gRPC/WebSocket/TCP） | 中（gRPC/HTTP/2 为主） |
| 安全策略 | TLS 终止、WAF、认证鉴权 | mTLS（可选）、网络策略 |
| 延迟要求 | P99 < 200ms | P99 < 5ms（单跳） |
| 治理重点 | 连接复用、TLS 缓存、灰度路由 | 连接池管理、eBPF 加速、拓扑感知路由 |
实践建议：在容器运行时治理中，建议将南北向与东西向流量治理分离。南北向使用独立的 Gateway 组件（如 Envoy Gateway、Kong），东西向则通过 Service Mesh（如 Istio、Linkerd）或 eBPF 方案（如 Cilium）实现。两者共享监控数据面，但治理策略独立配置，避免相互干扰。