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地址、配置网络接口和路由规则。其核心工作流程如下:
- ADD操作: kubelet调用CNI插件,传入Pod的命名空间ID和网络配置JSON。
- IP分配: 插件从IP地址管理(IPAM)模块获取一个可用的IP地址。
- 接口创建: 在宿主机和Pod命名空间之间创建veth pair,将一端放入Pod命名空间,另一端连接到宿主机网桥或路由设备。
- 路由配置: 在Pod命名空间内设置默认路由,在宿主机上添加到达Pod IP的路由条目。
- 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完全透明。
运维避坑: 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