4. 蓝绿发布网络模型：Service Mesh vs Cilium 原生路由、ClusterIP 与 EndpointSlice 在蓝绿切换中的行为
蓝绿发布的核心在于流量瞬间切换。在 Kubernetes 原生网络模型下，这种切换依赖 Service 与 EndpointSlice 的更新传播；而在 Service Mesh 模型中，流量切换由 Sidecar 代理的本地路由规则控制。Cilium 作为 eBPF 驱动的原生网络方案，提供了介于两者之间的高效路径。理解这三种模型在蓝绿切换中的行为差异，是进行网络参数调优的前提。
4.1 三种网络模型对比：Service Mesh vs Cilium 原生路由 vs 原生 kube-proxy
| 对比维度 | 原生 kube-proxy (iptables/IPVS) | Service Mesh (Istio/Linkerd) | Cilium 原生路由 (eBPF) |
|---|---|---|---|
| 数据平面 | 内核 iptables/IPVS 规则 | Sidecar 代理 (Envoy/Linkerd-proxy) | eBPF 程序挂载于网络钩子 |
| 控制平面 | kube-controller-manager | Istiod/Pilot + xDS 协议 | Cilium Agent + KV Store |
| 蓝绿切换机制 | 更新 Service 的 label selector | 更新 VirtualService/DestinationRule | 更新 CiliumEndpoint + EndpointSlice |
| 切换延迟 | 秒级 (iptables 规则更新) | 毫秒级 (本地 xDS 推送) | 亚毫秒级 (eBPF map 原子更新) |
| 流量观测 | 无原生观测能力 | 全链路可观测 (Tracing/Metrics) | Hubble 提供流日志与指标 |
| 资源开销 | 低 (内核规则) | 高 (每个 Pod 一个 Sidecar) | 极低 (eBPF 无额外进程) |
4.2 ClusterIP 在蓝绿切换中的行为
ClusterIP 是 Kubernetes Service 的默认类型，也是蓝绿发布中前端流量入口的核心抽象。当蓝绿版本切换时，ClusterIP 本身保持不变，但其背后的 EndpointSlice 对象会发生变化。
- 切换前： ClusterIP 的 EndpointSlice 仅包含蓝色版本 Pod 的 IP 列表。
- 切换中： 更新 Service 的 label selector，kube-controller-manager 开始生成新的 EndpointSlice。
- 切换后： EndpointSlice 仅包含绿色版本 Pod 的 IP 列表，旧 EndpointSlice 被删除。
在 Cilium 环境下，ClusterIP 的负载均衡由 eBPF 程序直接处理，不再经过 iptables。这意味着 ClusterIP 的切换延迟取决于 eBPF map 的更新速度，而非 iptables 规则的全量重写。
bpf-lb-map-max 参数（默认 65536），可以控制 ClusterIP 后端最大数量。在蓝绿发布场景中，如果后端 Pod 数量超过默认值，需要提前调大该参数，避免 eBPF map 溢出导致负载均衡失效。
4.3 EndpointSlice 在蓝绿切换中的行为
EndpointSlice 是 Kubernetes v1.21+ 默认启用的 API，用于替代传统的 Endpoints 对象。在蓝绿发布中，EndpointSlice 的更新行为直接影响流量切换的平滑度。
| 阶段 | EndpointSlice 状态 | 流量行为 |
|---|---|---|
| 蓝版本运行中 | 1 个 EndpointSlice，包含 3 个蓝色 Pod IP | 100% 流量到蓝色版本 |
| 绿版本就绪 | 2 个 EndpointSlice：蓝色 3 个 + 绿色 3 个 | 流量按权重分配（默认轮询） |
| 切换执行 | 更新 Service selector，触发 EndpointSlice 重建 | 短暂出现新旧 EndpointSlice 共存 |
| 切换完成 | 1 个 EndpointSlice，包含 3 个绿色 Pod IP | 100% 流量到绿色版本 |
externalTrafficPolicy 设置为 Local，则切换时可能出现部分连接被路由到旧 Pod 的情况。建议在蓝绿切换前将 externalTrafficPolicy 临时改为 Cluster，或使用 Cilium 的 --bpf-lb-svc-opt 参数优化本地流量处理。
4.4 Cilium 原生路由 vs Service Mesh：蓝绿切换流程对比
下图展示了 Cilium 原生路由与 Service Mesh 在蓝绿切换时的数据流差异。Cilium 通过 eBPF 直接在内核层完成流量切换，而 Service Mesh 需要经过 Sidecar 代理的二次转发。
4.5 蓝绿切换中的 EndpointSlice 更新时序与 Cilium 优化
EndpointSlice 的更新并非瞬时完成。从 Service selector 变更到所有 Cilium Agent 感知到新 EndpointSlice，存在一个时间窗口。下图展示了这个时序以及 Cilium 的优化策略。
4.6 蓝绿切换中的连接保持与优雅关闭
无论使用哪种网络模型，蓝绿切换时都需要处理存量连接。Cilium 提供了 cilium endpoint disconnect 命令和 --bpf-lb-rss-option 参数来优化连接迁移。
cilium bpf lb list 命令查看当前 ClusterIP 的后端分布。切换后，使用 cilium bpf lb flush 清理旧后端的连接跟踪条目，避免连接残留导致流量黑洞。
# 查看当前 ClusterIP 后端
cilium bpf lb list | grep <cluster-ip>
# 清理旧后端连接跟踪
cilium bpf ct flush global
# 验证新后端是否生效
cilium bpf lb list | grep <cluster-ip>在 Service Mesh 场景下，连接保持通常通过 Sidecar 的 drainTime 和 terminationDrainDuration 参数控制。而在 Cilium 原生路由中，连接保持依赖 eBPF 的 conntrack 模块，可以通过 --bpf-ct-global-max 参数调整最大连接跟踪条目数。
4.7 总结：选择适合蓝绿发布的网络模型
| 场景 | 推荐网络模型 | 理由 |
|---|---|---|
| 低延迟、高吞吐 (金融交易) | Cilium 原生路由 | 亚毫秒级切换，无 Sidecar 开销 |
| 全链路可观测、灰度发布 | Service Mesh | 丰富的路由规则和遥测能力 |
| 简单场景、快速迁移 | 原生 kube-proxy | 无需额外组件，运维简单 |
| 混合场景 (部分服务需要可观测) | Cilium + 部分 Service Mesh | Cilium 提供基础网络，Service Mesh 仅用于关键服务 |