k8s的几种网络结构
2026/7/23大约 6 分钟
在 Kubernetes (K8s) 的物理架构中,网络模式通常可以从「Pod 内部的网络通信模式」以及「集群级别的网络插件(CNI)实现模式」两个维度来进行解剖。
这是决定大模型算力集群通信延迟与吞吐量的底层生命线。
维度一:Pod 级别的四种网络模式(容器共享机制)
在 K8s 内部,可以通过配置 Pod 的 spec 显式改变其网络隔离级别。
1. Host 模式 (hostNetwork: true)
我们在前文聊 nodeexpose 时提到过这种暴力直通的机制。
- 物理实现:Pod 完全剥离网络隔离,直接物理共享宿主机的网络命名空间(Network Namespace)。
- 特点:Pod 内部看到的网卡、IP、端口和路由表与宿主机一模一样。如果在 Pod 里起一个 8080 端口的服务,会直接物理霸占宿主机的 8080 端口。
- 适用场景:极致压榨网络性能、完全不想经过任何容器网络损耗的重型 AI 算力节点(如分布式训练的 Worker)。
2. Container 模式 (Shareable / Container)
- 物理实现:新启动的容器物理指定加入到一个已经存在的容器的网络命名空间中。
- 特点:这两个容器共享同一个 IP、同一个网卡和同一套端口。它们之间可以通过
localhost进行纳秒级的片内超高速通信。 - 典型应用:K8s 最核心的 Pod 内部多容器(Sidecar 模式)。例如,大模型推理主容器与负责收集 Metrics 监控的 Sidecar 容器之间就是这种关系。
3. None 模式
- 物理实现:Pod 拥有自己独立的网络命名空间,但是 K8s 不为其配置任何网卡、IP 或路由规则,只留下一个本地环回网卡(
lo)。 - 适用场景:对安全性要求极高、完全不需要且禁止进行任何网络 I/O 的纯封闭式批处理计算任务。
4. Bridge 模式(默认模式)
- 物理实现:每个 Pod 拥有独立的网络命名空间,并通过一对虚拟网卡对(veth-pair)一头扎在 Pod 内部,一头物理焊接在宿主机的虚拟网桥(如
cni0或br0)上。 - 特点:这是标准的基础隔离模式,Pod 拥有完全独立的、由集群分配的虚拟 IP(如
10.244.x.x)。
维度二:集群级别(CNI 插件)的三种主流网络架构
当多台 8 卡服务器需要跨节点进行大模型、智能体的数据交互时,底层网络插件(CNI)如何打通节点边界,主要依赖以下三种工业架构:
1. Overlay 模式(隧道覆盖网络 —— 代表:Flannel VXLAN、Calico VXLAN)
大模型中小规模测试集群最常用的“百搭模式”。
【 Pod A (10.244.1.5) 】 ➔ 发出原始数据包 (源: 10.244.1.5, 目的: 10.244.2.8)
│
▼
【 宿主机 A 物理网卡 】 ➔ 物理内封:把原始包作为 Payload,外面再套一层物理机的真实 IP 头
│ (封包过程:添加 VXLAN 头部,将目的转换为 宿主机B 的物理 IP)
▼
【 物理交换机网络 】 ───> 像普通物理机流量一样,穿过 PCIe/网线 传输
│
▼
【 宿主机 B 物理网卡 】 ➔ 物理解封:剥离外层物理机外壳,还原出原始的 10.244.2.8 数据包
│
▼
【 Pod B (10.244.2.8) 】 ➔ 成功接收到纯净的原始包
- 技术原理:通过 VXLAN 或 Geneve 技术,在现有的物理三层网络之上,通过“封包-解包(Encapsulation/Decapsulation)”,强行在软件层虚拟出一张巨大的、跨机器的二层局域网。
- 优缺点:
- 优:对底层物理网络没有任何依赖,只要机器之间能 ping 通,就能一键拉起 K8s 网络。
- 缺:CPU 损耗大。每发送一个数据包,宿主机内核都要进行高频的封包和解包计算。在大模型万卡大流吞吐、需要极速同步梯度的场景下,绝对禁止使用此模式。
2. Underlay 模式(直接物理路由 —— 代表:Calico BGP、云厂商 ENI/Terway)
我们在 nodeexpose 篇章中深入剖析过的、专为高性能 AI 智算中心而生的网络方案。
【 Pod A (10.244.1.5) 】 ➔ 发出原始数据包
│
▼ (直接打向宿主机网关,没有任何封包损耗)
【 物理核心交换机 】 ➔ 交换机由于提前通过 BGP 学习到了路由:
│ 直接查表判断:“10.244.2.0/24 应该路由给 宿主机B 的物理端口”
▼
【 Pod B (10.244.2.8) 】 ➔ 纳秒级直接送达
- 技术原理:完全抛弃软件封包。
- 方案 A (Calico BGP):宿主机直接当成路由器,通过 BGP 协议把 Pod 的网段动态宣告给机房的物理核心交换机,让物理交换机直接负责 Pod 之间的路由转发。
- 方案 B (云厂商 ENI):直接调用云厂商 VPC 的底层网络 API,把真实的弹性网卡(VPC 内部真实二级 IP)物理插到容器内部。
- 优缺点:
- 优:几乎零网络损耗,通信性能等同于物理机直连,完美支持无损 RDMA 网络。
- 缺:对机房物理网络要求极高。物理交换机的路由表容量如果满了,就无法扩展更多节点;云厂商环境则高度绑定厂商特定的 CNI 驱动。
3. Routing 模式(直连路由模式 —— 代表:Flannel host-gw)
介于 Overlay 与 Underlay 之间的折中设计。
- 技术原理:不采用 BGP 这种高级协议,而是在每台宿主机的内核路由表里,死死硬编码写入其他所有节点的静态路由规则(例如:“要去节点 B 的 Pod,下一跳直接指向节点 B 的物理 IP”)。
- 优缺点:
- 优:没有封包开销,性能非常好。
- 缺:无法跨三层网络。所有宿主机必须物理处于同一个二层交换机(同一个局域网网段)内部。如果集群规模变大、跨了不同的机房机架或子网,该模式当场失效。
💡 工业界架构师的硬冷选型准则
- 如果你在做大模型微调/预训练算力集群(追求极致 Samples/s):
锁死 Underlay 模式(如云厂商原生 ENI/Terway 或者是自建机房的 Calico BGP 模式)。配合高性能网络 HPN 拓扑,直接打通物理层,把网络延迟压到物理极限。 - 如果你在做智能体(Agent)应用开发、微服务编排(追求弹性和研发敏捷度):
使用默认的 Overlay 模式(如 Calico/Flannel VXLAN)。此时网络开销不是第一瓶颈,研发团队能像玩乐高积木一样快速创建、销毁、迁移 Pod 的隔离优势才是最高优先级。
