2. Kubernetes 网络模型：Pod网络、Service网络、Ingress网络、CNI插件角色
Kubernetes 网络模型是容器编排中最核心也最复杂的抽象层之一。它定义了集群内所有工作负载（Pod、Service、Ingress）如何通信，以及外部流量如何进入集群。理解这三层网络与 CNI 插件的分工，是设计蓝绿发布网络准入控制与回滚方案的前提。
2.1 三层网络模型总览
Kubernetes 网络模型可拆解为三个逻辑层次，每一层解决不同的通信问题：
| 网络层 | 通信范围 | 核心对象 | 主要职责 |
|---|---|---|---|
| Pod 网络 | Pod ↔ Pod（跨节点） | Pod、Node | 为每个 Pod 分配唯一 IP，实现扁平化互通 |
| Service 网络 | 客户端 ↔ Pod 集群 | Service、EndpointSlice | 提供稳定的虚拟 IP 和负载均衡，屏蔽 Pod IP 变化 |
| Ingress 网络 | 外部流量 ↔ 集群内部 | Ingress、IngressController | 基于域名/路径的七层路由与 TLS 终结 |
关键认知： 蓝绿发布中的流量切换，本质上是 Service 网络 的标签选择器切换（ClusterIP 不变）与 Ingress 网络 的后端权重调整。Pod 网络本身不参与发布决策，但 CNI 插件的网络策略能力决定了准入控制的粒度。
2.2 Pod 网络：扁平 IP 与 CNI 实现
Kubernetes 要求所有 Pod 之间可以不通过 NAT 直接通信，无论它们是否在同一节点。这一“扁平 IP 模型”由 CNI 插件负责实现。
2.2.1 Pod 网络的核心约束
- 每个 Pod 拥有独立 IP：容器共享 Pod 的网络命名空间（Network Namespace）。
- 跨节点直通：Pod IP 在集群内全局可达，不依赖端口映射。
- 无 NAT 通信：Pod 访问其他 Pod 或 Service 时，源 IP 保持不变。
2.2.2 CNI 插件在 Pod 网络中的角色
CNI 插件是 Pod 网络的真正执行者。当 kubelet 需要创建 Pod 时，它会调用 CNI 插件完成以下步骤：
- 创建 veth pair：一端接入 Pod 网络命名空间，另一端接入宿主机 root 命名空间（通常桥接到 cni0 网桥）。
- 分配 IP 地址：从集群 IP 池（如 10.244.0.0/16）中分配一个唯一 IP。
- 配置路由：在宿主机和 Pod 内添加路由规则，确保跨节点流量能通过 Overlay 隧道或 BGP 路由到达。
- 可选：应用网络策略：部分 CNI 插件（如 Calico、Cilium）支持 NetworkPolicy，实现 Pod 级防火墙。
蓝绿发布关联： 在蓝绿发布中，新版本 Pod（绿）与旧版本 Pod（蓝）运行在同一个 Pod 网络中，拥有独立的 IP。CNI 插件必须保证新 Pod 创建后能立即被 Service 网络发现，且旧 Pod 销毁前已从 Service 端点列表中移除。这一过程依赖 CNI 的 IP 分配与回收速度。
2.3 Service 网络：虚拟 IP 与负载均衡
Pod 是易失的，其 IP 会随重建而变化。Service 网络通过引入稳定的虚拟 IP（ClusterIP）和标签选择器，为客户端提供可靠的访问入口。
2.3.1 Service 网络的核心机制
- ClusterIP：虚拟 IP，仅在集群内部可达，由 kube-proxy 通过 iptables/IPVS/eBPF 实现。
- EndpointSlice：动态维护符合标签选择器的 Pod IP 列表，当 Pod 创建或销毁时自动更新。
- 负载均衡：kube-proxy 将发往 ClusterIP 的流量随机或按权重转发到后端 Pod。
2.3.2 Service 网络与蓝绿发布
蓝绿发布的核心操作就是修改 Service 的 selector 字段，将流量从旧版本 Pod 切换到新版本 Pod：
# 蓝版本 Service 选择器
apiVersion: v1
kind: Service
metadata:
name: my-app-svc
spec:
selector:
app: my-app
version: blue # 指向蓝版本
ports:
- port: 80
targetPort: 8080# 切换为绿版本后，只需修改 selector
spec:
selector:
app: my-app
version: green # 指向绿版本
注意： 直接修改 selector 会导致流量瞬间切换，无法实现灰度或金丝雀发布。在生产环境中，建议使用 多个 Service（如 svc-blue、svc-green）配合 Ingress 权重路由，或使用 Service Mesh 实现更精细的流量管理。
2.4 Ingress 网络：七层路由与外部入口
Service 网络仅提供四层（TCP/UDP）负载均衡，且 ClusterIP 仅在集群内部可达。Ingress 网络解决了外部流量如何按域名/路径路由到集群内部 Service 的问题。
2.4.1 Ingress 网络的核心组件
| 组件 | 职责 | 示例 |
|---|---|---|
| Ingress 资源 | 声明路由规则（域名、路径、后端 Service） | YAML 配置 |
| Ingress Controller | 实际运行的反向代理（Nginx、Traefik、HAProxy） | ingress-nginx |
| TLS 证书 | HTTPS 终结，证书管理 | Secret 资源 |
2.4.2 Ingress 在蓝绿发布中的高级用法
通过 Ingress 的 权重路由 或 Header 路由，可以实现比 Service selector 切换更精细的流量控制：
# Nginx Ingress 权重路由示例（通过 annotation）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10" # 10% 流量到绿版本
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-green # 绿版本 Service
port:
number: 80
蓝绿发布最佳实践： 使用 Ingress 的 canary 机制，先引流 10% 到绿版本，观察无异常后再逐步提升权重至 100%，最后删除蓝版本。这种方式比直接修改 Service selector 更安全，支持快速回滚（将权重重置为 0）。
2.5 CNI 插件的完整角色定位
CNI 插件是 Kubernetes 网络模型的底层执行者，其职责贯穿 Pod 网络、Service 网络和 Ingress 网络：
| 网络层 | CNI 插件直接参与 | CNI 插件间接影响 |
|---|---|---|
| Pod 网络 | IP 分配、veth 创建、路由配置、Overlay 隧道 | Pod 启动速度、网络延迟 |
| Service 网络 | 部分 CNI（如 Cilium）通过 eBPF 替代 kube-proxy 实现 Service 转发 | Service 更新延迟、连接跟踪性能 |
| Ingress 网络 | 不直接参与，但提供底层网络策略支持 | 外部流量进入 Pod 的路径延迟 |
| 网络策略 | 实现 NetworkPolicy 的 Pod 级防火墙规则 | 蓝绿发布期间的隔离与准入控制 |
选型建议： 对于蓝绿发布场景，推荐使用 Cilium 或 Calico。Cilium 基于 eBPF 实现，Service 转发延迟低，且支持 L7 网络策略；Calico 成熟稳定，NetworkPolicy 功能完善，适合大规模集群。
2.6 本章小结
- Pod 网络 提供扁平 IP 模型，CNI 插件负责 IP 分配与跨节点路由。
- Service 网络 通过 ClusterIP 和 kube-proxy 实现稳定的服务发现与负载均衡，是蓝绿发布流量切换的直接操作点。
- Ingress 网络 提供七层路由能力，支持权重路由和金丝雀发布，是生产级蓝绿发布的首选入口。
- CNI 插件 是网络模型的底层基石，其性能与功能直接影响蓝绿发布的切换速度、隔离能力和回滚效率。