2. 容器网络基础:CNI插件原理、Overlay网络模型、Pod网络命名空间、网络策略基础

2.1 Pod网络命名空间:容器网络的隔离基石

每个Pod在Kubernetes集群中都有一个独立的网络命名空间(Network Namespace)。这个命名空间为Pod内的所有容器提供了共享的网络栈,包括独立的网络接口、路由表、ARP表和iptables规则。容器之间通过localhost即可通信,而Pod与Pod之间则必须通过真实的宿主机网络或Overlay网络进行交互。

关键运维认知: Pod网络命名空间的创建与销毁是容器网络运维中最频繁的操作之一。在灰度批次巡检中,需要关注命名空间泄漏或残留问题,特别是在高密度部署场景下,残留的虚拟网卡(veth pair)会消耗宿主机资源。

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

容器网络接口(CNI,Container Network Interface)是Kubernetes与网络插件之间的标准协议。CNI插件负责在Pod创建时为其分配IP地址、配置网络接口和路由规则。其核心工作流程如下:

  1. ADD操作: kubelet调用CNI插件,传入Pod的命名空间ID和网络配置JSON。
  2. IP分配: 插件从IP地址管理(IPAM)模块获取一个可用的IP地址。
  3. 接口创建: 在宿主机和Pod命名空间之间创建veth pair,将一端放入Pod命名空间,另一端连接到宿主机网桥或路由设备。
  4. 路由配置: 在Pod命名空间内设置默认路由,在宿主机上添加到达Pod IP的路由条目。
  5. DEL操作: Pod删除时,CNI插件清理网络接口、释放IP地址。
CNI插件类型 代表实现 网络模型 适用场景
Overlay Calico (VXLAN/IPIP), Flannel (VXLAN), Weave 封装隧道 跨主机通信,无需修改底层网络
路由 Calico (BGP), Cilium (eBPF) 直接路由 高性能,低延迟,需底层网络支持
云厂商原生 AWS VPC CNI, Azure CNI, GKE Dataplane V2 云VPC集成 云原生环境,Pod IP直通VPC
巡检提示: 在灰度批次发布中,CNI插件的ADD/DEL操作耗时直接影响Pod启动速度。建议在巡检清单中记录每次CNI调用的延迟分布,重点关注P99延迟是否超过500ms。

2.3 Overlay网络模型:跨主机通信的封装隧道

Overlay网络通过在宿主机网络之上构建虚拟隧道,实现Pod IP跨主机可达。最常见的Overlay模式是VXLAN(Virtual Extensible LAN),它将Pod数据包封装在UDP报文中,通过宿主机物理网络传输。封装和解封装过程对Pod完全透明。

VXLAN Overlay 网络模型:Pod跨主机通信流程 宿主机A (Node A) Pod A eth0: 10.1.1.2 veth pair veth A (宿主机端) 连接到网桥/路由 VTEP (VXLAN Tunnel Endpoint) 封装: 内层IP(10.1.1.2) → UDP(宿主机IP) 物理网卡 eth0: 192.168.1.10 宿主机B (Node B) Pod B eth0: 10.1.2.3 veth pair veth B (宿主机端) 连接到网桥/路由 VTEP (VXLAN Tunnel Endpoint) 解封装: UDP → 内层IP(10.1.2.3) 物理网卡 eth0: 192.168.1.20 物理网络 (Underlay) UDP封装: 源192.168.1.10 → 目标192.168.1.20 Pod IP (10.1.x.x) 在物理网络中不可见,仅存在于VXLAN隧道内部
运维避坑: Overlay网络引入的封装开销(VXLAN约50字节头部)可能导致MTU问题。如果宿主机物理网络MTU为1500,则Pod内MTU应设置为1450。在灰度批次巡检中,务必检查Pod内MTU配置是否与宿主机一致,否则会导致TCP分段和性能下降。

2.4 网络策略基础:Pod粒度的访问控制

Kubernetes NetworkPolicy是一种以Pod为单位的防火墙规则,通过标签选择器定义哪些Pod可以相互通信。网络策略由CNI插件(如Calico、Cilium)在宿主机上通过iptables、eBPF或IPVS规则实现。

网络策略的核心要素包括:

  • Pod选择器: 通过标签匹配目标Pod组。
  • 入站规则(Ingress): 允许哪些来源访问目标Pod。
  • 出站规则(Egress): 允许目标Pod访问哪些目的地。
  • 策略类型: 默认拒绝所有入站/出站流量,仅显式允许的流量通过。
# 示例:允许frontend命名空间中的Pod访问backend命名空间中的Pod(仅TCP 8080端口)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - protocol: TCP
      port: 8080
网络策略行为 默认规则 策略生效后 常见巡检问题
入站流量 允许所有 仅允许匹配的源 策略未覆盖导致服务不可达
出站流量 允许所有 仅允许匹配的目标 DNS解析被阻断(需显式放行kube-dns)
策略叠加 无 多条策略取并集 策略冲突导致规则膨胀
灰度批次巡检要点: 在灰度发布过程中,新旧版本Pod可能同时运行。如果网络策略使用了podSelector且未包含版本标签,新Pod可能被旧Pod的流量意外访问。建议在灰度批次中为每个版本添加独立的网络策略,或使用ipBlock精确控制来源IP范围。

2.5 关键运维指标与巡检清单

在容器网络运维中,以下指标需要在灰度批次巡检中重点记录:

  • CNI插件ADD延迟: 从kubelet调用CNI到Pod网络就绪的时间,正常应 < 200ms。
  • Overlay封装开销: 检查Pod内MTU与宿主机MTU的差值,确保VXLAN场景下Pod MTU = 宿主机MTU - 50。
  • 网络策略规则数: 每个节点的iptables/eBPF规则数量,超过5000条可能影响转发性能。
  • veth pair残留: 检查宿主机上/sys/class/net中是否存在已删除Pod的veth接口。
  • ARP表项溢出: 大规模集群中,Overlay网络的ARP表项可能超过内核限制(默认2048)。
留痕清单模板: 在灰度批次巡检报告中,建议按以下格式记录网络基础状态:
批次ID: gray-v2.1.0 | 节点: node-03 | CNI ADD P99: 180ms | MTU: 1450/1500 | 策略规则: 234条 | veth残留: 0 | ARP表项: 1560/2048