3、蓝绿发布原理：蓝绿环境定义、流量切换机制、零停机目标

蓝绿发布（Blue-Green Deployment）是Kubernetes生态中最常用的零停机发布策略之一。其核心思想是维护两套独立的生产环境（蓝环境与绿环境），通过瞬间切换流量路由器实现版本升级，从而避免传统滚动更新中“新旧共存”带来的兼容性问题。

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

在K8s中，蓝绿环境通常通过命名空间（Namespace）或标签选择器（Label Selector）进行逻辑隔离。两套环境各自包含完整的应用栈：Deployment、Service、ConfigMap、Secret等资源。

3.2 流量切换机制

蓝绿发布的核心操作是流量切换。在K8s中，最常用的切换方式是通过更新 Service 的 spec.selector 实现。切换过程通常分为以下步骤：

1. 部署绿环境：创建新版本的 Deployment，等待 Pod 全部 Ready。
2. 验证绿环境：通过 ClusterIP 或内部 DNS 直接访问绿环境 Pod 进行冒烟测试。
3. 执行切换：更新 Service 的 selector，将标签从 version: blue 改为 version: green。
4. 确认切换：观察 Service Endpoints 是否全部指向绿环境 Pod。
5. 保留蓝环境：蓝环境 Pod 保持运行，用于快速回滚。

# 查看当前 Service 的 selector
kubectl get svc myapp-svc -o jsonpath='{.spec.selector}'

# 切换流量到绿环境（version: green）
kubectl patch svc myapp-svc -p '{"spec":{"selector":{"app":"myapp","version":"green"}}}'

# 验证 Endpoints 是否更新
kubectl get endpoints myapp-svc

3.3 零停机目标与关键指标

蓝绿发布的核心目标是实现零停机（Zero Downtime）。这意味着在版本切换过程中，用户请求不应被中断或返回错误。衡量零停机效果的关键指标包括：

3.4 蓝绿环境资源对比

蓝绿发布需要同时运行两套完整的环境，资源开销是传统滚动更新的 2 倍。以下对比表帮助理解不同发布策略的资源消耗：

3.5 零停机的关键保障措施

要实现真正的零停机，蓝绿发布需要配合以下K8s原生机制：

• Readiness Probe（就绪探针）：确保新版本 Pod 真正就绪后才接收流量。切换前应确认绿环境所有 Pod 的 Readiness Probe 通过。
• PreStop Hook（停止前钩子）：在 Pod 被删除前执行优雅关闭，等待现有请求处理完成（通常设置 sleep 5 或调用应用的健康检查接口）。
• Service 的 Session Affinity（会话亲和性）：如果应用依赖 Session，切换时需注意客户端 IP 绑定。建议使用外部 Session 存储（如 Redis）避免亲和性问题。
• Endpoint 传播延迟：K8s 的 Endpoint 更新并非实时，通常有 1-3 秒的传播延迟。可通过 kubectl get endpoints 确认全部更新后再关闭蓝环境。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 5 && /app/graceful-shutdown"]

3.6 蓝绿发布的适用边界

蓝绿发布并非万能，以下场景需要谨慎评估：