2. 容器网络基础：Docker网络模型、CNI插件原理与Pod网络命名空间
容器网络是蓝绿发布流量切换与故障排查的底层基础设施。本章深入剖析Docker原生网络模型、Kubernetes CNI插件机制以及Pod网络命名空间的核心原理，为后续自动化诊断与流水线集成奠定理论基础。
2.1 Docker网络模型
Docker提供多种网络驱动，每种驱动对应不同的隔离级别与性能特征。在生产环境中，Bridge与Overlay是最常用的两种模式。
| 网络模式 | 隔离级别 | 跨主机通信 | 典型场景 |
|---|---|---|---|
| Bridge | 单主机 | 不支持 | 开发环境、单机部署 |
| Host | 无隔离 | 依赖主机网络 | 性能敏感型应用 |
| Overlay | 跨主机 | 支持（VXLAN） | Swarm集群、多节点服务 |
| Macvlan | 物理网卡级 | 支持 | 需要独立MAC地址的场景 |
| None | 完全隔离 | 不支持 | 自定义网络栈 |
2.1.1 Bridge模式
Docker默认模式。容器通过虚拟网卡对（veth pair）连接到宿主机上的docker0网桥，通过NAT实现对外通信。容器间可直接通过IP互通，但无法被宿主机外部直接访问（需端口映射）。
2.1.2 Host模式
容器直接使用宿主机网络栈，不进行网络隔离。性能最高，但存在端口冲突风险，且容器内应用与宿主机共享同一网络命名空间。
2.1.3 Overlay模式
基于VXLAN封装技术，在宿主机之间建立二层隧道，使跨主机的容器如同在同一子网内通信。Docker Swarm模式下默认使用此模型，也是Kubernetes早期网络方案的基础。
排查要点： 蓝绿发布中，若流量无法正确路由到新版本容器，首先检查Overlay网络隧道状态（
docker network inspect）以及宿主机之间的VXLAN端口（UDP 4789）是否可达。
2.2 CNI插件原理
Kubernetes不内置网络实现，而是通过CNI（Container Network Interface）标准接口与第三方插件交互。CNI插件负责为Pod分配IP、配置网络接口并维护网络策略。
2.2.1 CNI工作流程
- ADD操作： kubelet调用CNI插件，传入容器ID、网络命名空间路径及网络配置。
- IP分配： 插件从IPAM（IP Address Management）模块获取可用IP地址。
- 接口创建： 创建veth pair，一端放入Pod命名空间，另一端连接到宿主机网桥或Overlay隧道。
- 路由配置： 在宿主机和Pod内分别添加路由规则，确保数据包正确转发。
- DEL操作： Pod删除时，插件释放IP并清理网络接口。
2.2.2 主流CNI插件对比
| 插件 | 数据平面 | 网络策略支持 | 性能特征 |
|---|---|---|---|
| Calico | BGP / eBPF | 原生支持 | 高吞吐，低延迟 |
| Flannel | VXLAN / Host-GW | 需额外组件 | 简单易用，性能适中 |
| Cilium | eBPF | 原生支持 | 极高性能，可观测性强 |
| Weave | VXLAN / FastDP | 原生支持 | 加密通信，自动拓扑 |
故障排查关键： 蓝绿发布中，若新版本Pod无法接收流量，优先检查CNI插件是否成功执行ADD操作。查看kubelet日志（
journalctl -u kubelet）以及CNI插件二进制文件是否存在（/opt/cni/bin/）。
2.3 Pod网络命名空间
Kubernetes中每个Pod拥有独立的网络命名空间（Network Namespace），包含自己的网络栈：网卡、路由表、iptables规则等。Pod内所有容器共享此命名空间，通过localhost互相通信。
2.3.1 网络命名空间结构
- eth0： Pod主网卡，由CNI插件创建，连接至宿主机网桥或Overlay网络。
- lo： 回环接口，用于Pod内部容器间通信。
- 路由表： 包含默认网关（通常指向宿主机网桥IP）及集群CIDR路由。
- iptables规则： 由kube-proxy或网络策略控制器注入，实现Service负载均衡与访问控制。
2.3.2 与Docker网络命名空间的差异
| 维度 | Docker容器 | Kubernetes Pod |
|---|---|---|
| 命名空间粒度 | 每个容器独立 | Pod内所有容器共享 |
| IP分配 | Docker daemon分配 | CNI插件通过IPAM分配 |
| 网络策略 | 无原生支持 | 通过NetworkPolicy对象实现 |
| 生命周期 | 随容器启停 | 随Pod启停，与容器解耦 |
蓝绿发布关联： 在蓝绿发布切换时，新版本Pod的网络命名空间必须与Service的标签选择器匹配，否则流量无法路由。排查时使用
kubectl exec -it <pod> -- ip addr查看Pod内网卡状态，确认IP是否在Service的Endpoint列表中。
2.4 网络故障排查基础命令
掌握以下命令，可在蓝绿发布网络异常时快速定位问题根因。
| 命令 | 作用 | 排查场景 |
|---|---|---|
ip netns list |
列出所有网络命名空间 | 确认Pod命名空间是否存在 |
nsenter -t <pid> -n ip addr |
进入Pod命名空间查看网卡 | 检查eth0是否获取到IP |
bridge fdb show |
查看Overlay隧道转发表 | 确认跨主机MAC地址学习是否正常 |
iptables -t nat -L -n |
查看NAT规则 | 检查Service DNAT规则是否生效 |
tcpdump -i any port 4789 |
抓取VXLAN封装包 | 验证Overlay隧道是否通 |
实战建议： 在蓝绿发布流水线中，建议在部署新版本后自动执行网络连通性检查（如
curl测试Service IP），并将结果输出到流水线日志。若网络异常，立即触发回滚并调用上述排查命令生成诊断报告。