LinuxKubernetes网络模型教程_CNI原理与实战

10次阅读

Kubernetes 网络模型的核心是 IP-per-Pod,即每个 Pod 拥有独立可路由 IP 且跨节点直连不依赖 NAT;它通过 CNI 插件实现网络配置,主流插件包括 Flannel、Calico 和 Cilium,排查网络问题需依次检查插件状态、路由表和防火墙端口。

LinuxKubernetes 网络模型教程_CNI 原理与实战

Kubernetes 网络模型的核心,是让每个 Pod 拥有独立、可 路由 的 IP 地址,且所有 Pod 之间无需 NAT 就能直接通信。它不自己实现网络,而是通过标准化接口 CNI(Container Network Interface)委托给插件完成。理解这一点,就抓住了整个 K8s 网络的起点。

Pod 网络:IP-per-Pod 是基石

每个 Pod 被分配一个唯一 IP,其内部容器共享该网络命名空间——它们用 localhost 通信,对外表现为一个整体。这个 IP 必须能在集群任意节点间直接访问,即:

  • Pod 到 Pod:跨节点直连,不走 NAT 或 端口 映射
  • Node 到 Pod:宿主机进程可直接 ping 或 curl Pod IP
  • Pod 到 Service:通过 ClusterIP 实现虚拟服务抽象

CNI 插件怎么工作:从创建到就绪

当 kubelet 启动一个 Pod,会调用 CNI 插件执行 ADD 操作。典型流程如下:

  • 先启动 pause 容器,建立独立的网络命名空间
  • 调用 CNI 配置文件 指定的插件(如 bridge、flannel、calico)
  • 插件创建 veth pair:一端接入 Pod,另一端挂到宿主机 cni0 网桥
  • 为 Pod 分配 IP(由 host-local 或 static 等 IPAM 模块完成)
  • 配置路由规则,确保目标 Pod 子网 流量能正确转发(例如指向 flannel.1 或 cali* 接口)

完成后,kubelet 收到结果,Pod 网络即就绪。删除时则触发 Del 操作清理资源。

主流 CNI 插件选型关键点

不同插件解决不同场景,选型要看规模、性能、策略需求:

  • Flannel:轻量简单,VXLAN 封装兼容性好;host-gw 模式零封装但要求二层互通。适合中小集群或快速验证
  • Calico:基于 BGP 构建三层路由,无 Overlay 开销;原生支持 NetworkPolicy;大规模下可用 Route Reflector 降低连接数
  • Cilium:eBPF 内核级处理,绕过 iptables;支持 L7 策略(HTTP/gRPC)、可观测性和服务网格集成。适合高安全、高性能生产环境

排查网络不通的三个必查环节

遇到 Pod 间 ping 不通,按顺序检查:

  • 确认 CNI 插件 Pod 运行正常(kubectl get pods -n kube-system | grep -E "flannel|calico|cilium"
  • 检查节点路由表是否包含其他节点的 Pod 子网(ip route | grep 10.244 或对应 CIDR)
  • 验证 VXLAN/UDP 端口(如 Flannel 默认 8472)或 BGP 端口(Calico 默认 179)未被 防火墙 拦截
text=ZqhQzanResources