2. Kubernetes 核心网络模型：Service、Endpoint、Pod IP 与 Cluster IP 的关系
在蓝绿发布场景中，流量切换的本质是修改 Service 的标签选择器，使其指向新版本 Pod。要理解这一过程，必须先厘清 Kubernetes 网络模型中的四个核心概念：Pod IP、Cluster IP、Service 与 Endpoint。它们构成了集群内部流量的完整转发链路。
2.1 四层抽象与职责
下表从网络层级、生命周期、访问范围三个维度对比这四个概念：
| 概念 | 网络层级 | 生命周期 | 访问范围 | 核心职责 |
|---|---|---|---|---|
| Pod IP | L3（网络层） | 随 Pod 创建/销毁 | 集群内可达 | 容器网络接口（CNI）分配的虚拟 IP，Pod 间直接通信 |
| Cluster IP | L4（传输层） | 随 Service 创建/销毁 | 集群内部虚拟 IP | Service 的稳定入口，不随 Pod 变化 |
| Service | L4 抽象 | 持久化资源对象 | 集群内/外（NodePort/LB） | 定义访问策略、标签选择器、端口映射 |
| Endpoint | L4 映射 | 自动同步 | 集群内部 | 维护 Service 后端 Pod IP:Port 的实时列表 |
关键认知：Pod IP 是“动态的”，每次 Pod 重启都可能变化；Cluster IP 是“静态的”，Service 不删除就不会变。蓝绿发布正是利用这一特性，让客户端始终访问不变的 Cluster IP，而后端 Pod 通过 Endpoint 动态切换。
2.2 流量转发链路：从 Cluster IP 到 Pod IP
当集群内部客户端（如另一个 Pod）通过 Service 名称或 Cluster IP 发起请求时，Kubernetes 内置的 kube-proxy 组件负责将流量转发到具体的 Pod IP。完整的转发链路如下：
- DNS 解析：客户端通过 CoreDNS 将 Service 名称解析为 Cluster IP。
- iptables/IPVS 规则匹配：kube-proxy 在宿主机上维护的规则将目标 Cluster IP:Port 匹配到对应的 Endpoint 列表。
- 负载均衡选择：从 Endpoint 列表中按策略（随机、轮询等）选中一个 Pod IP:Port。
- CNI 网络转发：数据包经过宿主机网络栈、CNI 插件（如 Calico、Flannel）到达目标 Pod 的网卡。
蓝绿发布启示：修改 Service 的
spec.selector 后，Endpoint 控制器会在秒级内更新 Endpoint 对象，kube-proxy 随之更新节点转发规则。这一机制是流量切换的底层保障。
2.3 核心关系：Service ↔ Endpoint ↔ Pod
下图展示了三者的数据流与控制流关系：
2.4 蓝绿发布中的流量切换本质
在蓝绿发布流程中，Service 的 spec.selector 是唯一的“切换开关”。以下是一个典型的切换过程：
# 初始状态：Service 指向蓝色版本（v1）
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
version: v1 # <-- 指向蓝色
ports:
- port: 80
targetPort: 8080
# 切换后：Service 指向绿色版本（v2）
# 只需修改 selector 中的 version 值
spec:
selector:
app: myapp
version: v2 # <-- 指向绿色
注意：修改 selector 后，Endpoint 控制器会立即移除旧版本 Pod 的 IP，添加新版本 Pod 的 IP。但 kube-proxy 在节点上的规则更新存在秒级延迟（通常 1-5 秒），这期间可能出现“流量毛刺”——部分请求仍被转发到已被删除的旧 Pod。生产环境建议配合 preStop hook 和 readiness probe 实现优雅流量切换。
2.5 关键差异速查表
| 对比维度 | Pod IP | Cluster IP | Service | Endpoint |
|---|---|---|---|---|
| 是否可路由 | 是（集群内） | 是（虚拟） | 逻辑对象 | 逻辑对象 |
| 是否持久 | 否 | 是 | 是 | 自动同步 |
| 是否支持负载均衡 | 否 | 是（通过 kube-proxy） | 定义策略 | 提供后端列表 |
| 蓝绿切换中的作用 | 被替换的目标 | 不变的访问入口 | 切换的执行者 | 切换的实时反映 |
2.6 常见误区与避坑
- 误区一：认为 Cluster IP 可以直接 ping 通。Cluster IP 是 iptables/IPVS 虚拟 IP，仅对 TCP/UDP/SCTP 流量生效，ICMP 协议会被丢弃。
- 误区二：认为修改 Service selector 后流量立即切换。实际存在 Endpoint 同步延迟 + kube-proxy 规则更新延迟，建议在切换前确认旧 Pod 的
terminationGracePeriodSeconds设置。 - 误区三：忽略
externalTrafficPolicy的影响。当设置为Local时，流量只会转发到节点本地的 Pod，可能导致负载不均。 - 误区四：认为 Endpoint 只能由 Service 自动管理。可以手动创建
Endpoints对象将 Service 指向外部服务，但蓝绿发布场景中不建议这样做，会破坏自动化。
最佳实践：在蓝绿发布门禁系统中，建议在切换 Service selector 前，先通过
kubectl get endpoints 确认新版本 Pod 的 IP 已全部就绪，再执行切换操作。切换后持续监控 kubectl get endpoints -w 直到旧版本 IP 完全消失。