3. 蓝绿发布原理：蓝绿环境定义、流量切换机制、零停机部署模型

蓝绿发布（Blue-Green Deployment）是 Kubernetes 生态中最经典的零停机发布策略之一。其核心思想是维护两套完全独立的生产环境——蓝环境（当前稳定版本）与绿环境（新版本候选），通过一次性流量切换完成版本升级，从而将发布风险与停机时间降至最低。

3.1 蓝绿环境定义与资源隔离

在 K8s 中，蓝绿环境并非物理集群的隔离，而是通过 命名空间（Namespace）、标签选择器（Label Selector） 和 Service 端点（Endpoints） 实现逻辑隔离。两套环境共享同一集群，但拥有独立的 Deployment、Service 和 ConfigMap 实例。

3.2 流量切换机制

蓝绿发布的核心操作是 Service 选择器切换。通过修改主 Service 的 spec.selector 字段，将流量从蓝环境的 Pod 瞬间重定向到绿环境的 Pod。K8s 的 iptables/IPVS 规则在 Endpoints 变更后毫秒级生效，实现平滑切换。

# 切换前：主 Service 指向蓝环境
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: v1.0   # 指向蓝环境
  ports:
    - port: 80
      targetPort: 8080

# 切换后：主 Service 指向绿环境
# 只需将 version 改为 v2.0
spec:
  selector:
    app: myapp
    version: v2.0   # 指向绿环境

流量切换的完整步骤分为三个阶段：

1. 预部署验证：绿环境部署完成后，通过预发布 Service（app-service-preview）验证新版本功能、性能与兼容性。
2. 主 Service 切换：确认绿环境健康后，将主 Service 的选择器从 version: v1.0 改为 version: v2.0。
3. 蓝环境回收：观察一段时间（通常 15-30 分钟），确认无异常后删除蓝环境 Deployment 及相关资源。

3.3 零停机部署模型

零停机的核心在于 就绪探针（Readiness Probe） 与 优雅关闭（Graceful Shutdown） 的协同工作。蓝绿发布通过以下机制确保切换过程中无连接中断：

• 就绪探针前置检查：绿环境的 Pod 必须通过就绪探针（HTTP/TCP/gRPC）验证后才能被 Service 纳入 Endpoints 列表。探针失败时，Pod 自动从负载均衡池中移除。
• 连接排空（Connection Draining）：切换前，蓝环境的 Pod 应进入 preStop 钩子，等待现有请求处理完毕（通常 30-60 秒），再终止进程。
• 会话亲和性（Session Affinity）：若业务依赖用户会话，需在 Service 中设置 sessionAffinity: ClientIP，确保切换后同一用户的请求仍路由到同一版本 Pod（或通过外部 Session Store 解耦）。

3.4 蓝绿发布的 RPO 影响与灾备关联

在灾备自动化场景中，蓝绿发布直接影响 恢复点目标（RPO）：

• 正向影响：蓝绿环境可同时作为灾备切换的预演平台。在切换前，绿环境已承载完整生产流量副本，RPO 趋近于零。
• 反向风险：若蓝绿环境共享同一持久化存储（如 NFS、RWO 卷），切换后新版本写入的数据可能污染旧版本的回滚路径。建议使用 ReadWriteMany（RWX） 卷或独立卷快照来隔离数据。