Kubernetes网络模型深度解析：Pod跨节点直连通信与Calico实现原理

在 Kubernetes 集群中，Pod 与 Pod 之间可以直接通信是一个基本假设：无论它们是否位于同一节点，都不需要 NAT 或端口映射。这看似理所当然，但其背后的实现机制却体现了 Kubernetes 网络模型的设计哲学。本文将系统解析这一模型的核心原则，并重点拆解基于 Calico 的跨节点 Pod 通信全流程。

01 Kubernetes 网络模型的三大基本假设

Kubernetes 对集群网络提出了三个必须满足的前提条件，也称为网络模型的“三条铁律”：

① 每个 Pod 都有一个独立 IP

• Pod 不共享 Node 的 IP 地址。
• Pod IP 在整个集群内唯一。
• Pod 在其生命周期内 IP 地址保持不变。

这使得每个 Pod 在逻辑上如同一台拥有独立网络身份的主机。

② Pod 与 Pod 可以直接通信

• 无论 Pod 是否在同一节点上。
• 通信过程不需要网络地址转换（NAT）。
• 不需要额外的代理或端口映射。

这确保了应用层通信方式与传统物理机或虚拟机环境保持一致，降低了架构复杂度。

③ Node 与 Pod 之间可以直接通信

• Node 能够直接访问其 Pod 的 IP。
• Pod 也能够直接访问其所在 Node 的 IP。

这一点对于运维操作、健康探针以及 kubelet 与 Pod 的通信至关重要。

核心结论：Kubernetes 本身并不实现具体的网络功能，它只定义规则和接口。实际的网络能力完全由 CNI 插件 提供。

02 Pod 网络的本质：每个 Pod 都像一台主机

在 Kubernetes 的网络视角中：

• Pod ≈ 一台拥有独立 IP 地址的主机。
• Service ≈ 服务的访问入口（提供虚拟 IP 和负载均衡）。
• CNI ≈ 负责实现“让这些拥有独立 IP 的 Pod 能够真正互通”的基础设施层。

因此，网络的复杂性和实现细节被下沉到了 CNI 插件层。

03 同节点 Pod 是如何通信的？

当两个 Pod 位于同一个 Node 上时，通信过程相对简单：

1. CNI 插件为每个 Pod 创建一对虚拟以太网设备（veth pair）。
2. 设备的一端放置在 Pod 的 Network Namespace 内。
3. 另一端接入 Node 上的虚拟网桥（例如常见的 cni0）。
4. 数据包通过 Linux Bridge 或 veth 设备在 Node 内部直接转发。

整个过程：

• 不经过 Node 的物理网卡。
• 不涉及跨主机网络。
• 性能损耗极低，几乎等同于同一台 Linux 主机上两个网络命名空间之间的通信。

04 跨节点 Pod 通信是关键难点

真正的挑战在于：当 Pod A 在 Node 1 上，而 Pod B 在 Node 2 上时，它们如何实现直接通信？

不同的 CNI 插件有不同的实现方案：

• Flannel：通常采用 Overlay 网络（如 VXLAN），通过隧道封装数据包。
• Calico：常用 Underlay 模式，利用 BGP 协议或 IPIP 隧道传递路由。
• Cilium：基于 eBPF 技术实现高性能的网络策略和数据转发。

下文我们将重点剖析 Calico（BGP 模式）的实现细节。

05 基于 Calico 的跨节点 Pod 通信全过程

假设一个典型场景：

• Pod A：IP 为 10.244.1.10，运行在 Node 1 上。
• Pod B：IP 为 10.244.2.20，运行在 Node 2 上。
• 网络插件使用 Calico，并工作在非 Overlay 的 BGP 模式。

① Calico 为每个 Node 分配 Pod CIDR

Calico 会为集群中的每个节点分配一个唯一的 Pod 子网（CIDR），例如：

• Node 1 负责 10.244.1.0/24 网段。
• Node 2 负责 10.244.2.0/24 网段。
  每个节点只响应和处理其自身 CIDR 范围内的 Pod IP。

② Calico 在节点之间同步路由信息

通过 BGP 协议，Calico 在各节点间同步路由信息：

• Node 1 学习到：通往 10.244.2.0/24 网段的路由下一跳是 Node 2。
• Node 2 学习到：通往 10.244.1.0/24 网段的路由下一跳是 Node 1。
  这些路由规则会被直接写入每个节点的 Linux 内核路由表中。

③ Pod A 发送数据包

当 Pod A 尝试访问 Pod B 时：

1. Pod A 生成目标 IP 为 10.244.2.20 的数据包。
2. 数据包离开 Pod 的网络命名空间，进入 Node 1 的网络协议栈。
3. Node 1 查询本机路由表，发现目标 IP 10.244.2.20 属于 10.244.2.0/24 网段，且下一跳指向 Node 2。
4. 数据包通过 Node 1 的物理网络接口直接发送给 Node 2。
   关键点：此过程没有对原始数据包进行封装，也没有进行网络地址转换（NAT）。

④ Node 2 接收并转发

数据包到达 Node 2 后：

1. Node 2 的网络层接收到数据包，检查目标 IP。
2. 发现目标 IP 10.244.2.20 属于本地管理的 Pod CIDR（10.244.2.0/24）。
3. 数据包通过对应的 veth pair 被直接转发到 Pod B 的网络命名空间内。
   至此，一次跨节点的 Pod 间直接通信完成。

⑤ 整个过程的关键特点

• 全局可路由：Pod IP 在整个集群范围内都是可路由的。
• 真实 IP 包：数据包以原始 IP 包的形式在网络中传输。
• 高性能：由于省去了封装/解封装开销，网络性能接近底层物理网络。
• 可观测性：网络路径清晰，便于进行监控和故障排查。
  这正是 Calico 的 Underlay 模式（尤其是 BGP）的核心优势所在。

06 如果是 Overlay（VXLAN / IPIP）会怎样？

在 Overlay 网络模式下（如 Flannel 的 VXLAN 或 Calico 的 IPIP 模式），通信过程有所不同：

• Pod 发出的原始数据包会被加上一个额外的外层封装。
• 外层封装的源目地址是 Node 的 IP。
• 封装后的数据包通过隧道（Tunnel）跨节点传输。
• 到达目标节点后，外层封装被移除，原始数据包被递送给目标 Pod。

模式对比：

（图示：Underlay 直接路由与 Overlay 隧道封装的对比）

07 为什么 Kubernetes 坚持“Pod 直连模型”？

根本原因在于：将复杂性下沉到基础设施层，从而极大降低应用层的复杂度。

如果没有这个模型，应用开发者将不得不：

• 让应用逻辑感知并处理 NAT 带来的影响。
• 精心规划和管理大量的端口映射。
• 实现更复杂的服务发现机制。
• 导致构建分布式系统的成本和复杂度急剧上升。

Kubernetes 通过定义清晰的网络模型，将这部分复杂性交由专业的 CNI 插件和集群运维人员处理。

08 小结：核心要点回顾

① Kubernetes 定义规则，不实现网络

集群的网络能力完全由用户选择的 CNI 插件提供和实现。

② Pod IP 是一等公民

Pod 被赋予独立的、稳定的 IP 地址，在网络层面被视为独立的主机，而非仅仅是一个容器端口。

③ Calico 通过路由实现跨节点直连

借助 BGP 等路由协议，Calico 实现了 Pod IP 在集群内的直接路由，通信过程不依赖 NAT 或代理。

④ Service 是访问入口，不是通信基础

Service 提供了稳定的服务发现和负载均衡入口，但 Pod 与 Pod 之间的基础通信并不依赖于 Service 资源。