📚 课程目录第4章网络策略与CNI

4. 蓝绿发布原理：蓝绿环境定义、流量切换机制、Ingress/Service策略、发布回滚流程

蓝绿发布（Blue-Green Deployment）是一种零停机或低风险的发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现流量的瞬间切换与快速回滚。在 Kubernetes 与 Velero 结合的运维场景中，理解蓝绿发布的底层原理是处理漂移告警与复测流程的基础。

4.1 蓝绿环境定义与核心概念

蓝绿环境的核心在于“隔离”与“一致性”。两套环境在基础设施、网络策略、存储卷声明（PVC）和数据层面必须保持对等，才能保证切换后业务无感。

维度	蓝环境（当前生产）	绿环境（新版本）
状态	承载 100% 生产流量	部署新版本，零流量或仅内部测试流量
数据层	使用生产数据库/存储	通常复用生产数据（只读挂载）或独立克隆
网络标识	Service 名称：`app-blue`	Service 名称：`app-green`
Ingress 路由	指向 `app-blue` Service	指向 `app-green` Service（切换后）
生命周期	长期运行	验证通过后接管流量，旧蓝环境回收

运维要点：在 Velero 备份策略中，蓝绿环境应分别配置独立的备份 Schedule。切换前对蓝环境做一次全量备份，切换后对绿环境立即执行一次验证性备份，确保恢复点覆盖两个版本。

4.2 流量切换机制：从 Ingress 到 Service 的路径

蓝绿发布的流量切换本质是修改 Ingress 资源中的 backend 指向，或调整 Service 的 selector 标签。Kubernetes 原生机制保证了切换的原子性与瞬时性。

4.2.1 基于 Ingress 的显式切换

通过更新 Ingress 规则中的 serviceName 字段，将流量从蓝 Service 指向绿 Service。此方式切换逻辑清晰，适合灰度验证后的全量切换。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-green   # 切换前为 app-blue
            port:
              number: 8080

4.2.2 基于 Service Selector 的隐式切换

保持 Ingress 不变，仅修改 Service 的 selector 标签，使其指向新版本 Pod。此方式无需重建 Ingress 资源，切换速度更快，但需要保证新旧 Pod 的标签不冲突。

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: v2   # 切换前为 v1
  ports:
  - port: 8080
    targetPort: 8080

漂移告警关联：当 Service Selector 切换后，若旧版本 Pod 未被及时缩容或标签残留，会导致 Service 后端同时包含新旧 Pod，引发流量比例漂移。Velero 的 pod-volume-backup 钩子应在此阶段检查 Endpoint 数量是否与预期一致。

4.3 Ingress/Service 策略与流量管理

在实际运维中，Ingress 与 Service 的配合策略决定了蓝绿切换的粒度与安全性。下表对比了三种常见策略的适用场景与风险。

策略	实现方式	切换粒度	回滚速度	适用场景
Ingress 后端切换	更新 Ingress 的 `serviceName`	域名/路径级别	中等（需重新加载 Ingress 配置）	全量发布、A/B 测试
Service Selector 切换	修改 Service 的 `selector` 标签	Service 级别	极快（kube-proxy 秒级同步）	紧急回滚、快速发布
双 Service + 权重切换	创建两个 Service，通过外部负载均衡器权重控制	百分比流量	慢（依赖外部 LB 配置）	金丝雀发布、灰度验证

  最佳实践：在 Velero 备份恢复的复测流程中，推荐使用 Ingress 后端切换 策略。因为 Ingress 资源本身可被 Velero 备份，切换记录作为 Kubernetes 资源版本历史留存，便于审计与回滚验证。

4.4 发布回滚流程：从切换失败到快速恢复

蓝绿发布的核心优势在于回滚的“瞬时性”。当绿环境验证失败或出现漂移告警时，只需将流量切回蓝环境即可。完整的回滚流程包含以下步骤：

触发回滚条件：监控系统检测到绿环境错误率上升、延迟超标或 Velero 备份校验失败。
确认蓝环境状态：检查蓝环境 Pod 是否仍在运行、Service Endpoint 是否健康、数据卷是否未卸载。
执行流量切换：将 Ingress 的 backend 重新指向蓝 Service，或恢复 Service 的 selector 为旧版本标签。
验证恢复结果：通过健康检查端点确认流量已 100% 回到蓝环境，无 502/503 错误。
隔离绿环境：保留绿环境 Pod 用于问题排查，但将其从 Service Endpoint 中移除（通过修改标签或缩容）。
记录回滚事件：将回滚操作记录到 Velero 的 Backup 注释或外部审计系统，便于后续复盘。

漂移告警复测关键点：回滚后必须执行一次 Velero 恢复验证，确认蓝环境的数据一致性未被绿环境的写入操作破坏。若绿环境在验证期间修改了共享存储中的数据，回滚后可能出现数据漂移，此时需从 Velero 备份中恢复受影响的数据卷。

4.5 蓝绿发布与 Velero 备份恢复的集成点

在《Velero处理容器网络运维蓝绿发布剧本漂移告警的复测流程》课程中，蓝绿发布原理是后续所有告警分析与复测操作的理论基础。以下是三个关键集成点：

备份策略对齐：蓝环境切换前执行 velero backup create，绿环境验证通过后执行增量备份，确保回滚点可用。
资源标签管理：为蓝绿环境的 Pod、Service、Ingress 打上 deployment-phase: blue 或 deployment-phase: green 标签，便于 Velero 按标签筛选备份范围。
恢复验证自动化：在 CI/CD 流水线中集成 Velero 的 restore --from-backup 命令，模拟回滚场景并自动校验 Service Endpoint 数量与 Ingress 规则是否恢复至切换前状态。