网络模型与 CNI
本教程共 65 篇 · 第 29 篇 · 更新于 2026-08-14 · 约 14 分钟阅读
本节目标：弄清 Kubernetes 对网络的基本假设（每个 Pod 有独立 IP、Pod 间直接互通），理解这套”网络模型”为何要这样设计，以及 CNI 插件如何把它变成现实。
前面几章讲了 Service、DNS、Ingress，全都是在”网络已经能通”的前提下聊的。可网络是怎么通的？为什么 Pod 能直接拿 IP 互相访问？这一章我们从底层看一眼。
29-1 Kubernetes 的网络假设
Kubernetes 不自己造一套网络，而是定了一套模型，要求底层网络去满足。这套模型只有几条，但每条都很硬：
- 每个 Pod 拥有自己独立的 IP 地址。
- 任何两个 Pod，不用 NAT（网络地址转换）就能直接互通。
- 节点上的 Pod 和节点自己的代理（agent）之间也能直接通信。
- Pod 看到的自己的 IP，和外面对它发起连接时用的 IP，是同一个。
第一条最反直觉。传统虚拟机里，一台机一个 IP；Kubernetes 里是一个容器组一个 IP。Pod 内部的容器共享这个 IP 和网络命名空间，彼此用 localhost 通信。
Note“IP-per-Pod” 是 Kubernetes 网络模型的核心。它让应用不用关心端口冲突，容器组之间就像连在普通网络上一样直白。
29-2 为什么不直接用节点 IP
你可能会想：干吗不让 Pod 共用节点 IP、靠不同端口区分？那样应用就得自己管理端口分配，端口撞了还得协调，痛苦得要命。
给每个 Pod 独立 IP，应用就能老老实实监听”标准端口”——Web 服务监听 80，数据库监听 5432，谁都不用迁就谁。这把网络复杂性从应用身上卸掉了。
Tip网络模型把”IP 管理”的责任从应用移到平台。开发者写代码时完全不用管端口规划，Kubernetes 替你兜着。
29-3 Service 的虚拟 IP 是另一回事
注意区分两种 IP。Pod IP 是真实的、数据面可达的地址；Service 的集群 IP（cluster IP）是虚拟的。
Pod 到 Pod 之间，走的是真实网络，经过 CNI 插件搭好的底层链路。而访问 Service 的虚拟 IP 时，是 kube-proxy 在节点上做了一层转发（用 iptables、IPVS 或 nftables 规则），把流量重定向到真实的 Pod IP。
所以逻辑上可以分成三层：
- 节点网络：物理机/虚拟机的真实网络，集群搭建时就有。
- Pod 网络：CNI 插件为每个 Pod 分配的Overlay或Underlay地址，让 Pod 互通。
- Service 网络：虚拟 IP 段，由 kube-proxy 维护转发规则。
29-4 CNI 是什么
CNI 全称 Container Network Interface（容器网络接口）。它不是某个具体实现，而是一份插件契约——它规定了”容器运行时（kubelet）该怎么调用网络插件来给 Pod 配网络”。
流程是这样的：kubelet 创建 Pod 时，容器运行时先起好容器，然后按 CNI 规范调用网络插件，插件负责给 Pod 插上网络（分配 IP、连到网桥、配路由），完成后把结果回报给 kubelet。
Note在 v1.36.2 里，容器运行时是 containerd 或 CRI-O，早已不提 dockershim。CNI 是它们和底层网络之间的标准接口。
29-5 常见的 CNI 插件
生态里主流的 CNI 实现有几类，选哪个取决于你需要什么能力：
- Flannel：最轻量，用 Overlay 网络（VXLAN）打通 Pod 网络。功能干净，适合入门和简单集群。
- Calico：主打高性能路由 + 网络策略。它既可以做纯三层路由，也能叠加 Overlay；还能直接在数据面落实 NetworkPolicy。
- Cilium：基于 eBPF，内核态处理网络、负载均衡和安全策略。性能好、可观测性强，是近年的热门选型。
- kube-router 等也是常见选项。
Warning并不是所有 CNI 都支持 NetworkPolicy。比如纯 Flannel 默认就不做网络策略隔离。想要东西向流量隔离，得选 Calico、Cilium 这类带策略能力的实现，或叠加 Canal。
29-6 CNI 怎么影响上层能力
底层网络插件直接决定了上层功能能不能用。三件和前面章节强相关的事：
- Service 转发：kube-proxy 不管 Pod 网络怎么搭，只管虚拟 IP 到 Pod IP 的转发。只要 Pod 能互通，Service 就通。
- 网络策略：只有支持 NetworkPolicy 的 CNI，写的
NetworkPolicy才会真正生效。否则写了也白写。 - 跨节点通信：Overlay 模式（VXLAN）在节点间封装隧道；路由模式下 Pod IP 直接走底层网络。前者省事，后者性能更好。
29-7 双栈（IPv4/IPv6）也要插件支持
Kubernetes 早就支持双栈网络。一个 Pod 可以同时拿到 IPv4 和 IPv6 地址，Service 也能是双协议族。但这同样依赖 CNI 插件正确分配两类地址。
配置双栈时，Service 的 spec.ipFamilies 可以指定 ["IPv4", "IPv6"]。不过这是进阶内容，先知道有这么回事即可。
29-8 kube-proxy 的角色别搞混
再强调一次：kube-proxy 不是 CNI 插件。它的职责是基于 Service 和 EndpointSlice，在每个节点上维护转发规则（iptables、IPVS 或 nftables 模式），让访问虚拟 IP 的流量落到正确 Pod。
CNI 解决”Pod 能不能互通”，kube-proxy 解决”虚拟 IP 怎么转到 Pod”。两者各管一段，配合起来才是完整的网络栈。
Tip排查网络问题时先想清楚：是 Pod 之间不通（CNI 的问题），还是访问 Service 不通（kube-proxy/EndpointSlice 的问题）。方向错了会很耗时。
小结
Kubernetes 网络模型的核心是”IP-per-Pod + 无 NAT 互通”。CNI 是插件契约，把这套模型落地成真实网络，Calico、Flannel、Cilium 是常见实现。
底层网络还决定了 Service 转发、网络策略隔离、双栈等能力能不能用。理解这一层，后面讲网络策略和南北向/东西向流量才站得住脚。
下一章讲 NetworkPolicy：在 CNI 之上，怎么用声明式规则把 Pod 之间的流量管起来。