CNI 与 K8s 网络插件

CNI 规范 · Flannel / Calico / Cilium 三大流派 · Overlay vs Underlay · 数据包链路与 IPAM · 多网卡

场景问题

K8s 里每个 Pod 都要有一个 IP，且要满足 K8s 的网络模型铁律：所有 Pod 无需 NAT 即可互通、Pod 看到的自己的 IP 与别人看到它的 IP 一致。可是 kubelet 自己不管网络——它创建完 Pod 的 network namespace 后，就把"给这个 netns 配网卡、分 IP、通路由"这件事外包出去。

问题来了：不同环境网络差异巨大——公有云 VPC、裸金属 BGP、跨可用区、Overlay 隧道……不可能有一个内置实现通吃。于是 K8s 定义了 CNI（Container Network Interface）规范：只约定"kubelet 怎么调你、传什么参数、你返回什么"，具体怎么组网由插件自由实现。

对游戏战斗集群还有额外诉求：低延迟、一机一 Pod（独占机器减少干扰）、有时需要多网卡（业务网 + 管理网分离）。这直接影响 CNI 选型。

打个比方：CNI 就像一纸"装修外包合同"。kubelet 只负责把毛坯房交出去（建好 Pod 的 network namespace），至于怎么通水电网（配网卡、分 IP、打通路由）它一概不碰，全甩给外包的装修队（CNI 插件）。合同（CNI 规范）只死板规定"我怎么叫你来、给你哪把钥匙（netns 路径和参数）、你干完回我一句成没成"，具体用什么材料工艺完全随你发挥——Flannel 图省事拉个 Overlay 隧道、Calico 走 BGP 专业布线、Cilium 上 eBPF 玩智能家居。类比失效边界：契约极简是优点，但也意味着 kubelet 完全不为组网结果背书——插件配错、IP 撞车、路由不通，kubelet 只看到"外包回了个失败"，真正排障得一头扎进插件内部。而且换插件≈换装修队重装，跨插件迁移一点都不平滑，选型时得想清楚再下手。

实现方案

CNI 规范：ADD / DEL / 可执行 + JSON

CNI 插件就是一个可执行文件，kubelet 通过环境变量传操作类型（CNI_COMMAND=ADD|DEL|CHECK）、netns 路径、容器 ID，通过 stdin 传 JSON 配置，插件通过 stdout 返回 JSON 结果。IPAM（IP 地址管理）是一个子职责，通常委托给独立的 IPAM 插件。

// kubelet 通过 stdin 传给 CNI 插件的配置（ADD 时）
{
  "cniVersion": "1.0.0",
  "name": "mynet",
  "type": "bridge",              // 主插件类型
  "bridge": "cni0",
  "isGateway": true,
  "ipam": {                       // IPAM 子职责：谁来分配 IP
    "type": "host-local",
    "subnet": "10.244.1.0/24",
    "routes": [{ "dst": "0.0.0.0/0" }]
  }
}

// 插件 ADD 成功后通过 stdout 返回的结果
{
  "cniVersion": "1.0.0",
  "interfaces": [{ "name": "eth0", "sandbox": "/var/run/netns/cni-xxxx" }],
  "ips": [{
    "address": "10.244.1.7/24",
    "gateway": "10.244.1.1",
    "interface": 0
  }]
}

DEL 时同样传 netns 与容器 ID，插件负责回收 IP、删 veth、清路由（幂等，Pod 已删也要能安全返回）。

网络平面三选一：Overlay / Underlay / hostNetwork

所有 CNI 方案，本质只在回答一个问题：底层网络（机房交换机 / 云上 VPC 路由表）认不认识 Pod IP？ 三种答案就是三种平面。

判据一句话：Pod IP 能不能被底层网络直接路由——不能就得套壳（Overlay），能就直接走（Underlay），懒得给 Pod 独立 IP 就共用宿主机（hostNetwork）。

打个比方：Overlay 像公司内部自编的"工位号"。快递员（底层交换机）根本不认工位号，所以每件快递出楼前都要再套一层写着"某某大厦 12 层"的外包装（VXLAN/IPIP 封装），到对面楼下前台拆开，再按工位号内投。Underlay 则是把工位号直接登记进城市邮政系统，快递员认，直投到人。hostNetwork 最省事——不设工位号，全公司共用前台一个地址，谁先占了分机 8000 别人就不能再占。

类比失效边界：外包装不是"多个盒子"这么无害——它每个包都要拆装（不是每批一次），还实打实吃掉 50 字节 MTU，忘了调 MTU 就是大包黑洞；而 Underlay 的"邮政登记"要底层点头（BGP 允许、VPC 配额够），不是想登记就能登记，公有云上常常直接被拒。

IPAM：谁来分配 IP

组网和"给谁哪个 IP"是两件事，后者由 IPAM（IP Address Management）子插件负责，主插件把 ipam 段委托出去：

IPAM 选错是IP 泄漏/耗尽的常见根因：host-local 状态在节点本地，Pod 异常删除未回收就会泄漏；集中式 IPAM 更好回收但依赖控制面。

IPAM 到底在干什么：两级分配

"Pod 的 IP 是谁给的"这题的完整答案是两级，只答一级就丢分：

1. 集群级切网段：kube-controller-manager 带 --allocate-node-cidrs --cluster-cidr=10.244.0.0/16 --node-cidr-mask-size=24，给每个 Node 切一块 Node.spec.podCIDR（如 NodeA 拿 10.244.1.0/24）。Calico 换成 IPPool + block、Cilium 换成 CiliumNode 资源，思路一样。
2. 节点级分单 IP：CNI 主插件把 ipam 段委托给子插件（host-local），它在本节点那块网段里取一个空闲 IP，落盘 /var/lib/cni/networks/<网络名>/<IP> 记录占用，把 IP + 网关 + 要写进 Pod netns 的路由一起返回给主插件。

所以 IPAM 交付的不只是一个 IP，而是四件事：① 分配全局唯一的 Pod IP（K8s 铁律，冲突即灾难）；② 给出网关地址（10.244.1.1，即网桥持有的地址）；③ 给出要写进 Pod 的路由（default via 网关）；④ DEL 时回收，以及回收失败后的 GC。

为什么必须按节点切段，而不是全局随手分？ 因为只有"一个节点 = 一段连续前缀"，跨节点的可达性才能聚合成一条路由（10.244.2.0/24 via NodeB）。否则宿主机路由表 / VXLAN fdb 的条目数就等于 Pod 数而不是节点数，几万 Pod 时内核表和控制面同步都会崩。IPAM 的网段划分方式，直接决定了跨节点转发能不能做得高效——这也是下一节 cross 模块的前提。

两个高频 IPAM 事故：① host-local 状态只在节点本地磁盘，kubelet 被强杀或节点异常重启后残留占用，ls /var/lib/cni/networks/cbr0 全是幽灵 IP，新 Pod 卡 ContainerCreating 并报 failed to allocate for range 0: no IP addresses available；② Calico 按 block（默认 /26，64 个 IP）向节点批发 IP 以减少访问控制面，碎片化时会出现"总量还够但本节点借不到"的假性耗尽，用 calicoctl ipam show --show-blocks 查借用情况。

三大流派原理对比

封装开销与 MTU（面试必答的性能账）：VXLAN/IPIP 每个包都要套一层外层头（VXLAN 约 50 字节、IPIP 约 20 字节），带来两笔成本：① CPU 封解包；② 有效 MTU 变小——底层 1500，overlay 后 Pod 侧要降到 1450（VXLAN），忘了改就会大包被分片或直接黑洞，表现为"小包通、大包/长连接 gRPC 偶发超时"。underlay 路由（host-gw / Calico BGP）不封包，无此税。

NetworkPolicy 落地差异：NetworkPolicy 是 K8s 的声明，但执行靠 CNI——不是所有 CNI 都实现。Flannel（纯 VXLAN）不支持，配了也不生效；Calico 用 Felix 下发 iptables/eBPF 规则执行；Cilium 用 eBPF 执行且支持到 L7（HTTP method/path）。选 CNI 前先确认它是否落地 NetworkPolicy，否则"策略写了个寂寞"。

eBPF 替代 kube-proxy 的取舍：Cilium 可开 kube-proxy replacement，把 Service→Endpoint 转发做进 eBPF map（O(1)），省掉 iptables/ipvs 整条链（kube-proxy 演进原理见 K8s 网络）。收益是大规模 Service 下延迟/同步成本骤降；代价是内核版本要求高（≥4.19、强推荐 ≥5.10）、排障需懂 eBPF、生态较新。

一个包的完整旅程：为什么要过"0 号网卡"

面试里常说的"0 号网卡"其实是一串不同的设备，先把名字对上号，后面的链路才不会乱：

三条路径分开看：

• 同节点 Pod ↔ Pod：Pod A 的 eth0 → veth → cni0。目标 10.244.1.8 与自己同网段，二层查 MAC 直接交换，压根不进宿主机的 IP 路由表。最短路径，没有任何封装。
• 跨节点 Pod ↔ Pod：Pod A → cni0 → 宿主路由表命中 10.244.2.0/24 dev flannel.1 → 内核在 VXLAN 设备上查 neigh（对端 VTEP 的 MAC）与 fdb（这个 MAC 在哪台 Node 上）→ 套上 VXLAN + UDP:8472 + 外层 IP（NodeA→NodeB）→ 从宿主 eth0 发出 → NodeB 收到 8472 → 解封 → flannel.1 → 路由到 cni0 → veth → Pod C。
• Pod → 公网：Pod → cni0 → 宿主默认路由 → iptables 的 MASQUERADE 把源地址 SNAT 成 Node IP（否则回包不认识 10.244.x.x）→ 物理网卡出去。

典型路由表长这样：

# Pod 内（netns 里）
default via 10.244.1.1 dev eth0            # 网关就是 cni0 持有的地址
10.244.1.0/24 dev eth0 scope link          # 同节点邻居走二层

# 宿主机上
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1   # 本机 Pod 网段
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink               # 对端节点整段，一条路由搞定

为什么要过 cni0 这个网桥？ veth 是一根点对点的"虚拟网线"，一端在 Pod、一端在宿主。如果宿主这端不插网桥，就得为每个 Pod 在宿主上单独加一条 /32 路由，同节点两个 Pod 通信还要绕三层。网桥把 N 根 veth 汇成一台虚拟交换机，一次买下三样东西：① 同节点 Pod 二层直通，不进 IP 路由；② 网桥自己持有网段网关 IP，于是 Pod 里只需要一条 default via 网关 的通用路由，不必给每个 Pod 定制；③ 出节点的流量在这里收敛成一个点再交给宿主路由表。一句话：网桥 = 同节点二层交换机 + 默认网关 + 流量收敛点。

为什么要过 flannel.1？ 因为封装必须发生在某个网卡上。它就是内核里的 VXLAN 设备（VTEP）：路由把对端 Pod 网段的下一跳指向它，内核在这个设备上查 neigh/fdb 拿到"对端 VTEP MAC + 对端 Node IP"，套壳后再交回宿主路由从物理网卡发走。它是 Pod-IP 平面 → Node-IP 平面的换乘站，没有它，虚构的 Pod IP 无处可去。tunl0 是 Calico IPIP 的同位角色，只套一层 20 字节外层 IP 头，没有 UDP 和 VNI。

ip -d link show flannel.1        # 看 vxlan id / 本地 VTEP IP
bridge fdb show dev flannel.1    # 对端 VTEP MAC → 对端 Node IP 的映射
ip neigh show dev flannel.1      # 对端 Pod 网段网关 → VTEP MAC
ip route get 10.244.2.9          # 内核实际会怎么走这个包
tcpdump -i any -nn udp port 8472 # 抓 VXLAN 外层，确认封装真发出去了

跨节点转发（cross）模块：Overlay 的必备零件

同节点靠网桥就够了，问题全出在跨节点：Pod IP 是集群自造的地址，底层交换机的路由表里根本没有 10.244.x.x 这一条，云上 VPC 还会开源地址校验，把它当伪造包直接丢掉。所以每个 Overlay CNI 都必须常驻一个"跨节点模块"（flanneld / Calico 的 Felix + BIRD / cilium-agent），干三件事：

1. 拓扑发现——谁负责哪一段：watch API Server 或 etcd 里的 Node.spec.podCIDR / CRD，维护 10.244.2.0/24 → NodeB(192.168.1.12) 这张映射表。
2. 数据面下发——把映射翻译成内核状态：写宿主机路由（via ... dev flannel.1）、写 VXLAN 的 neigh 与 fdb 表项；换成 Calico 就是用 BGP 把网段宣告给对端；换成 Cilium 就是写 eBPF map。
3. 持续对账——节点会变：节点上下线、网段回收、agent 重启后从期望状态幂等重建内核表项，而不是靠一次性初始化。

一句话分工：IPAM 决定"谁是谁"（地址归属），cross 模块决定"怎么到"（可达性）。两者必须对齐——IPAM 按节点切连续网段，cross 模块才能用一条聚合路由覆盖整台机器的 Pod。

CrossSubnet：只对真正跨子网的流量收封装税

• Calico：ipipMode: CrossSubnet 或 vxlanMode: CrossSubnet——同一个二层子网内的节点之间直接写路由（via 对端NodeIP dev eth0，零封装），只有跨子网/跨机房才落到 IPIP/VXLAN。
• Flannel："Backend": {"Type": "vxlan", "DirectRouting": true}，同样是"同子网直路由、跨子网才封装"。
• 收益：绝大多数流量在同机架/同可用区内，这部分完全不付封包 CPU 与 MTU 的税，同时跨子网依旧可达——对同 AZ 部署的游戏战斗集群是性价比最高的一档。
• 前提：同子网节点二层可达，且底层不做源地址校验（公有云上常常不满足，只能老实全程封装）。

什么时候需要自研 cross：标准 CNI 只保证单集群内一个平面。一旦多地域/多集群——Pod 网段可能重叠、跨 VPC 不通、云厂商禁自定义路由——就得另加一层：要么上 Submariner（网关节点 + IPsec/VXLAN 隧道打通集群间，网段冲突时用 GlobalNet 做 NAT），要么自研跨集群网关。本项目走的是更省事的第三条路：干脆不做跨集群 Pod 平面，用 hostNetwork + 业务级 Mesh 直接连宿主机内网 IP（见 K8s 网络）。

多插件链与多网卡

• CNI chaining：主插件（组网）+ 链式插件（如 portmap 做端口映射、bandwidth 限速、tuning 调 sysctl），按顺序执行。
• Multus：给一个 Pod 挂多张网卡——比如战斗服 eth0 走业务 overlay、net1 直连高性能 underlay/SR-IOV 做玩家流量。游戏"一机一 Pod + 业务/管理网分离"常用。

为什么这么做

• 为什么 K8s 把网络外包给 CNI：网络环境千差万别，内置死一种实现会限制所有人。可执行 + JSON 的极简契约让插件生态百花齐放，谁都能实现。
• 为什么大规模/低延迟倾向 BGP/eBPF 而非 VXLAN：VXLAN 每个包都要封装外层 UDP/IP 头，CPU 花在封解包上，且 MTU 变小易触发分片/性能悬崖。BGP 路由是原生三层转发无封包；eBPF 在内核态直接查 map 转发，两者都省掉 overlay 税，延迟与吞吐更好。游戏战斗流量对延迟敏感，优先它们。

为什么别的选择不行

排障应对清单（现象 → 定位路径）

CNI 层最常见的四类故障与定位顺序（更宏观的集群踩坑见 K8s 网络 的生产踩坑清单，此处只给网络插件侧的定位路径）：

沉淀结论

相关专题：eBPF 原理与落地 · Istio 与 Cilium 服务网格 · K8s 网络 · 容器运行时 · 全栈极限低延迟

记忆口诀

• CNI 契约：可执行文件 / stdin JSON 入 / stdout JSON 出 / ADD·DEL·CHECK
• 触发链：kubelet →CRI→ 运行时 →调 CNI（不是 kubelet 直接调）
• 三平面判据：底层认不认 Pod IP —— 不认=Overlay要封装 / 认=Underlay原生转发 / 不给Pod IP=hostNetwork
• 包的旅程：Pod eth0 →veth→ cni0(同节点二层直通) →宿主路由→ flannel.1 封 VXLAN →宿主 eth0；出公网加 MASQUERADE
• 网桥非必需：Calico 无 cni0 / veth + proxy_arp(169.254.1.1) + 每 Pod /32 路由，全三层
• cross 三件事：拓扑发现(谁管哪段) / 数据面下发(路由·fdb·neigh·BGP·eBPF map) / 幂等对账
• CrossSubnet：同子网直路由零封装 / 跨子网才 IPIP·VXLAN
• IPAM 两级：controller-manager 切 podCIDR / host-local 节点内分单 IP；按节点切段才能聚合路由
• 规模账：cluster-cidr /16 + mask /24 = 256 节点 × 254 Pod，建集群时定死
• IPAM：host-local 本地顺序 / DHCP 租底层 / 集中式(Calico·Cilium·VPC-CNI)
• 三流派：Flannel=VXLAN overlay / Calico=BGP underlay 路由 / Cilium=eBPF 内核态
• Overlay vs Underlay：通用性换性能 / 封包税 + MTU 缩水 / 能三层路由就别付税
• NetworkPolicy：K8s 声明·CNI 执行 / Flannel 不支持 / Calico·Cilium 支持(Cilium 到 L7)
• 排障：跨节点看 VXLAN/BGP / 大包超时查 MTU / 起不来查 IPAM / 策略不生效先看 CNI 支不支持
• 游戏诉求：低延迟 / 一机一 Pod / Multus 多网卡 → 推向 BGP·eBPF

内容来源

综合整理。参考方向：CNI 官方规范（containernetworking/cni SPEC，ADD/DEL/CHECK、IPAM 约定）、Flannel / Calico / Cilium 官方文档与数据面原理、VXLAN(RFC 7348) 与 BGP 路由基础、Multus / CNI chaining 文档、K8s 网络模型（Pod 无 NAT 互通）官方说明。

自测：合上资料能说清楚吗？

1. K8s 为什么不内置一种网络实现，而要把组网外包给 CNI？CNI 的契约到底约定了什么？

2. Flannel(VXLAN) 与 Calico(BGP) 的数据面原理差在哪？为什么低延迟战斗集群更偏向后者？

3. 为什么在公有云上 Calico 常被迫回退 IPIP？这带来什么代价？

4. CNI chaining 与 Multus 各解决什么问题？游戏场景怎么用？

5. Cilium 相比 Calico 的核心差异是什么？各自的前提约束？

6. Overlay 与 Underlay 的判据到底是什么？各自的代价是什么？

7. 一个包从 Pod A 到另一台节点的 Pod C，完整经过哪些网卡？为什么要过 cni0 和 flannel.1？

8. Overlay 为什么必须有一个"跨节点（cross）模块"？它具体做哪三件事？CrossSubnet 又优化了什么？

9. Pod 的 IP 到底是谁分的？为什么必须按节点切连续网段？--cluster-cidr=10.244.0.0/16 能带多少节点？

10. 配了 NetworkPolicy 却不生效，排查顺序是什么？大包偶发超时又怎么定位？