2、容器网络基础回顾:CNI插件原理、Overlay网络模型(VXLAN/IPIP)、Pod网络命名空间与veth pair

在深入缓存命中巡检与网络策略验证之前,必须牢固掌握容器网络的三大基石:CNI插件机制、Overlay网络模型以及Pod网络命名空间与veth pair。这三者构成了Kubernetes集群中Pod间通信的完整链路,也是后续所有运维操作的基础。

2.1 CNI插件原理:网络配置的标准化接口

CNI(Container Network Interface)是Kubernetes与容器运行时之间的网络配置协议。它定义了一个标准化的插件接口,使得任何符合CNI规范的网络方案(如Calico、Flannel、Weave)都能无缝接入集群。

核心流程:当kubelet创建Pod时,会调用容器运行时(如containerd),运行时在创建完网络命名空间后,通过CNI插件完成网络配置。整个过程分为ADD(添加)、DEL(删除)、CHECK(检查)三个操作。

CNI插件工作流程

  1. 调用入口:kubelet通过容器运行时调用CNI插件二进制文件(如/opt/cni/bin/bridge)。
  2. 配置读取:插件读取CNI配置文件(通常位于/etc/cni/net.d/),获取网络类型、子网、网关等参数。
  3. 网络创建:插件创建veth pair,一端连接Pod网络命名空间,另一端连接宿主机网桥或底层网络设备。
  4. IP分配:调用IPAM(IP Address Management)插件(如host-local、dhcp)为Pod分配IP地址。
  5. 路由配置:在宿主机和Pod命名空间内添加必要的路由规则,确保Pod可达。
CNI操作 触发时机 典型动作
ADD Pod创建时 创建veth pair、分配IP、配置路由
DEL Pod删除时 清理veth、释放IP、删除路由
CHECK 周期性健康检查 验证网络配置是否一致,不一致则触发修复
运维要点:排查Pod网络异常时,首先检查CNI插件日志(通常位于/var/log/cni/或通过journalctl -u kubelet查看)。常见问题包括:IPAM地址池耗尽、veth pair创建失败、网桥配置冲突。

2.2 Overlay网络模型:VXLAN与IPIP

Overlay网络通过在现有物理网络(Underlay)之上构建虚拟化网络层,解决了跨宿主机Pod通信的隔离与寻址问题。VXLAN和IPIP是两种最主流的Overlay封装技术。

2.2.1 VXLAN(Virtual Extensible LAN)

VXLAN使用MAC-in-UDP封装,将二层以太网帧封装在UDP数据包中,通过三层网络传输。它支持多达1600万个虚拟网络标识符(VNI),远超传统VLAN的4096个。

  • 封装格式:原始数据帧 → VXLAN头部(8字节,含VNI)→ UDP头部(8字节)→ 外部IP头部(20字节)→ 外部MAC头部(14字节)。
  • MTU影响:VXLAN额外增加50字节开销,因此宿主机MTU需设置为1500 - 50 = 1450(或启用巨型帧)。
  • 典型实现:Flannel VXLAN模式、Calico VXLAN模式。

2.2.2 IPIP(IP in IP)

IPIP使用IP-in-IP封装,将原始IP数据包直接封装在另一个IP数据包中。它比VXLAN更轻量,但仅支持三层通信,不支持广播/多播。

  • 封装格式:原始IP数据包 → IPIP头部(20字节)→ 外部IP头部(20字节)。
  • MTU影响:IPIP额外增加20字节开销,MTU需设置为1500 - 20 = 1480。
  • 典型实现:Flannel IPIP模式、Calico IPIP模式(默认)。
对比维度 VXLAN IPIP
封装层 二层(MAC-in-UDP) 三层(IP-in-IP)
额外开销 50字节 20字节
网络标识 VNI(24位,1600万+) 无(依赖外部IP)
广播/多播 支持(需多播组或BGP EVPN) 不支持
性能 略低(UDP封装+校验和) 较高(纯IP封装)
适用场景 需要二层广播、大规模多租户 纯三层通信、追求性能
MTU配置警告:Overlay网络最常见的故障是MTU不匹配导致的数据包分片或丢包。务必确保宿主机物理网卡、隧道接口、Pod网卡以及中间网络设备的MTU一致。建议宿主机MTU设置为1500时,隧道接口MTU设为1450(VXLAN)或1480(IPIP),Pod网卡MTU设为1450或1480。
Overlay网络模型:VXLAN与IPIP封装对比 VXLAN 封装结构 原始以太网帧(14+20+Payload) VXLAN头部(8字节,含VNI) UDP头部(8字节) 总开销:50字节 | MTU建议:1450 IPIP 封装结构 原始IP数据包(20+Payload) IPIP头部(20字节) 外部IP头部(20字节) 总开销:20字节 | MTU建议:1480 运维关键点 1. VXLAN适合需要二层广播的场景(如ARP、DHCP),但UDP封装增加CPU开销。 2. IPIP性能更优,但无法穿越NAT设备(外部IP头部可能被修改)。 3. 无论哪种模式,MTU一致性是避免分片丢包的第一道防线。 4. 生产环境建议启用硬件Offload(如GENEVE/GRO/GSO)降低封装开销。

2.3 Pod网络命名空间与veth pair

每个Pod拥有独立的网络命名空间(Network Namespace),提供隔离的网络栈(包括网卡、路由表、iptables规则等)。veth pair(虚拟以太网对)则是连接Pod命名空间与宿主机命名空间的“网线”。

2.3.1 网络命名空间隔离

网络命名空间是Linux内核提供的网络隔离机制。每个Pod的网络命名空间包含:

  • 独立网卡:通常为eth0,通过veth pair连接到宿主机。
  • 独立路由表:定义Pod的默认网关、直连路由等。
  • 独立iptables规则:用于Pod内的网络策略(如NetworkPolicy)。
  • 独立网络栈:包括ARP表、socket缓冲区等。

2.3.2 veth pair工作原理

veth pair是一对虚拟网卡,数据包从一端进入,立即从另一端出来。在容器网络中:

  1. 一端(veth0):放置在Pod网络命名空间内,命名为eth0,配置Pod IP地址。
  2. 另一端(veth1):放置在宿主机网络命名空间内,通常连接到cni0网桥或直接配置路由。
  3. 数据流转:Pod发送数据包 → eth0 → veth pair → veth1 → 宿主机网桥/路由 → 目标。
排查命令示例:查看Pod网络命名空间内的网卡和路由:
# 进入Pod网络命名空间
nsenter -t $(docker inspect -f '{{.State.Pid}}' ) -n ip addr
nsenter -t $(docker inspect -f '{{.State.Pid}}' ) -n ip route

# 查看宿主机上对应的veth pair
ip link show | grep veth
ethtool -S vethXXXXX  # 查看veth统计信息(收发包、丢包等)
Pod网络命名空间与veth pair连接结构 Pod A 网络命名空间 eth0: 10.1.1.2/24 路由: default via 10.1.1.1 iptables规则 veth pair 数据流 宿主机网络命名空间 veth1: 无IP cni0网桥: 10.1.1.1/24 宿主机路由表 cni0 网桥 连接所有Pod veth pair 运维检查清单 1. 检查veth pair状态:ip link show | grep veth,确保状态为UP。 2. 查看veth统计信息:ethtool -S vethXXXXX,关注rx_dropped/tx_dropped。 3. 验证Pod内eth0与宿主机veth的MAC地址对应关系(通过ip neigh)。 4. 常见故障:veth pair一端被误删除、网桥端口老化、MTU不匹配导致丢包。

2.4 三者协同:从Pod到Pod的完整数据路径

理解CNI、Overlay、veth pair如何协同工作,是排查网络问题的关键。以下是一个Pod A(宿主机1)访问Pod B(宿主机2)的完整数据路径:

  1. Pod A发送数据包:数据包从Pod A的eth0(veth pair一端)发出,目标IP为Pod B的IP。
  2. 宿主机网桥处理:数据包通过veth pair到达宿主机1的cni0网桥,网桥根据目标MAC地址决定转发。
  3. 路由决策:宿主机1的路由表发现目标IP不在本地子网,将数据包转发到Overlay隧道接口(如flannel.1或tunl0)。
  4. Overlay封装:隧道接口根据目标Pod所在的宿主机IP,对原始数据包进行VXLAN或IPIP封装。
  5. 物理网络传输:封装后的数据包通过宿主机1的物理网卡发送到宿主机2。
  6. Overlay解封装:宿主机2的隧道接口接收数据包,解封装还原原始数据包。
  7. 宿主机网桥转发:宿主机2的cni0网桥根据目标MAC地址,将数据包通过veth pair发送到Pod B的eth0。
巡检切入点:当Pod间通信延迟高或丢包时,逐段检查:Pod内eth0 → veth pair → cni0网桥 → 隧道接口 → 物理网卡。使用tcpdump在每段抓包,对比封装前后的源/目标IP,快速定位故障点。