Kubernetes 网络模型与 CNI 总览

摘要：本文面向生产 SRE / 架构师，梳理 Kubernetes 网络模型的核心约束、Pod IP 与 Service 虚拟 IP 的关系，以及 CNI 插件（Calico / Cilium / Flannel）的选型差异。覆盖版本：Kubernetes v1.28+。

适用版本与前提

• Kubernetes：v1.28+（文中 kube-proxy 的 nftables 模式稳定于 v1.33，ipvs 在 v1.35 标记为弃用，见下文）。
• 工具：kubectl、crictl/ctr、节点 shell 权限（排障需要）。
• 前提：已具备集群访问权限，了解 Pod / Service 基本概念。

背景与问题

Kubernetes 只定义了网络应该是什么样，并不自带网络实现。官方文档明确：集群网络由 CNI（Container Network Interface）插件提供（来源：Kubernetes 官方文档 - Cluster Networking）。这带来两个后果：

1. 不同发行版、不同云厂商的“网络行为”并不完全一致，排障时必须先确认你的 CNI 与版本。
2. 网络是 K8s 里最容易出现“能通但说不清为什么”的部分，必须建立模型才能推理。

核心概念：四大约束

Kubernetes 网络模型对“连通性”提出了一组基本承诺（官方称为 networking model），可归纳为：

1. Pod 之间互通：任意节点的 Pod 可以访问任意其他节点的 Pod，且不需要 NAT——两端看到的是彼此的真实 Pod IP。
2. 节点代理与 Pod 互通：节点上的系统组件（kubelet、容器运行时）能与本节点上的所有 Pod 直接通信。
3. 每个 Pod 独立 IP：Pod 是网络的最小单元，一个 Pod 内多个容器共享同一网络命名空间（通过 pause 容器持有）。
4. IP 稳定于 Pod 生命周期：Pod IP 在重建后会变化（因此才需要 Service 抽象）。

心智模型

把集群想象成“一个扁平的大二层/三层网络”：所有 Pod 都在同一个可路由的地址空间里。CNI 的职责就是让这个承诺在真实节点网络上成立。

CNI 的职责

kubelet 在创建/删除 Pod 时，通过标准 exec 接口调用 CNI 插件，完成三件事：

• IPAM：给 Pod 分配 IP（从节点子网或全局池）。
• 网络配置：创建 veth pair、接入网桥或虚拟设备、写路由。
• 策略与清理：根据 NetworkPolicy 下发规则，Pod 删除时回收 IP。

注意

集群没有可用的 CNI 就无法运行任何 Pod。kubeadm 初始化后第一件事就是安装 CNI；若 CNI 未就绪，kubectl get pods 会一直处于 ContainerCreating。

主流 CNI 对比

CNI	数据面	NetworkPolicy	典型场景	内核/运维要求
Flannel	VXLAN / host-gw	不支持（需叠加 Calico 等）	入门、学习、简单集群	最低
Calico	iptables（默认）/ eBPF（可选）	原生，业界标准	生产主流、强策略	中等
Cilium	eBPF（默认）	原生，能力强	大规模、高性能、可观测	内核 5.8+ 更佳 [版本相关]

关键差异：

• Flannel 哲学是“先通再说”，只解决连通性，默认不实现 NetworkPolicy，生产若需要微隔离必须另配策略控制器。
• Calico 像“运营一张真实的三层 IP 网络”，支持 BGP 直连（无封装开销）或 VXLAN Overlay，NetworkPolicy 成熟。
• Cilium 基于 eBPF，可在内核态做转发、负载均衡与策略，规则规模大时性能优势明显，并自带 Hubble 可观测性。[厂商特定]

关于 kube-proxy 的演进

kube-proxy 负责把 Service 虚拟 IP 翻译成 Pod IP，常见模式：

• iptables（默认，线性规则链，规模大时更新慢）。
• ipvs（哈希表，O(1)，但 在 v1.35 标记为弃用，官方推荐迁移到 nftables）。
• nftables（v1.33 起 GA，官方推荐用于 Linux 节点）。
• eBPF：Cilium 等可实现“无 kube-proxy”数据面（kubeProxyReplacement）[厂商特定]。

具体默认值以目标版本 release notes 为准 [版本相关]。

Service 与 Pod IP 的关系（总览）

Pod IP 是易变的，Service 提供稳定的虚拟 IP（ClusterIP）+ 标签选择器 + 负载均衡。本目录下 service.md、headless-service.md、ingress.md 等文章分别展开。这里只给出整体流量路径：

生产实践

• 新集群选型：通用生产首选 Calico；追求性能/可观测/大规模优先 Cilium；学习环境可用 Flannel。
• MTU 一致性：Overlay（VXLAN/IP-in-IP）会封装，通常节点 MTU 1500 时 Pod 网络 MTU 应为 1450（VXLAN 开销 50 字节）。两端不一致会导致大包丢包（见 troubleshooting.md）。
• 网络策略：默认集群是“全通”的，生产应在关键命名空间启用默认拒绝（见 networkpolicy.md）。
• 可观测性：开启 CNI 的 metrics（如 Cilium Hubble、Calico Felix metrics）与 CoreDNS 的 :9153 指标。

常见坑

• ClusterIP 无法 ping：因为 ClusterIP 是虚拟 IP，没有真实接口响应 ICMP，只处理 TCP/UDP（由 kube-proxy 拦截做 DNAT）。这不是故障。
• CNI 未安装导致全集群 ContainerCreating：先 kubectl get pods -n kube-system 看 CNI DaemonSet 是否 Ready。
• Node 内核版本过低：Cilium eBPF 需要较新内核，老旧内核会回退或报错 [厂商特定]。

FAQ

Q：一个集群能混用多个 CNI 吗？ A：通常不能让两个 CNI 同时管理主网络。但可通过 Multus 在主 CNI 之外附加次要网络接口（多网卡场景）。

Q：CNI 之间如何迁移？ A：没有无损在线迁移的通用方案。一般需新建集群或在维护窗口内重建节点网络。迁移前务必备份并演练 [未实测]。

参考资料

• Kubernetes 官方文档 - Cluster Networking，访问日期：2026-10-08。
• Kubernetes 官方文档 - Service，访问日期：2026-10-08。
• CNI 规范（containernetworking/cni），访问日期：2026-10-08。
• Calico 官方文档，访问日期：2026-10-08。
• Cilium 官方文档，访问日期：2026-10-08。
• Flannel 项目，访问日期：2026-10-08。
• Spacelift - Kubernetes Networking Explained（kube-proxy 模式与 nftables/ipvs 弃用说明），访问日期：2026-10-08。