4、蓝绿发布在K8s中的实现方式

在 Kubernetes 生态中，蓝绿发布的核心思想是同时维护两套独立的生产环境（蓝环境与绿环境），通过流量调度机制在瞬间完成版本切换。根据网络栈层次和组件选型的不同，主流实现方式分为三种：Service Selector 切换、Ingress 路由切换 和 Service Mesh 切换。三种方式在隔离粒度、切换速度、可观测性和运维复杂度上各有优劣。

4.1 通过 Service Selector 切换

这是最基础、最轻量的实现方式，完全利用 Kubernetes 原生 Service 的 selector 字段完成流量切换。蓝环境和绿环境各自部署一组 Pod，共享同一个 Service 名称，通过修改 Service 的 selector 标签选择器，将流量瞬间从旧版本 Pod 转移到新版本 Pod。

操作步骤

1. 部署蓝环境：创建 Deployment app-v1，Pod 标签为 app: myapp, version: blue。
2. 创建 Service：Service 的 selector 设置为 app: myapp, version: blue，此时流量全部进入蓝环境。
3. 部署绿环境：创建 Deployment app-v2，Pod 标签为 app: myapp, version: green。绿环境 Pod 启动并通过 Readiness Probe 后，Service 尚未选择它们。
4. 执行切换：更新 Service 的 selector 为 app: myapp, version: green。kube-controller-manager 检测到变更，更新 EndpointSlice，kube-proxy 同步 iptables/IPVS 规则。
5. 验证与回滚：确认绿环境正常后，删除蓝环境 Deployment；若异常，将 selector 改回 version: blue 即可秒级回滚。

关键配置示例

# 切换前的 Service
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
    version: blue    # 流量指向蓝环境
  ports:
    - port: 80
      targetPort: 8080

# 切换时只需将 version 改为 green
# kubectl patch svc myapp-svc -p '{"spec":{"selector":{"version":"green"}}}'

优缺点对比

4.2 通过 Ingress 路由切换

当集群使用 Ingress Controller（如 Nginx Ingress、Traefik、HAProxy Ingress）时，可以在 Ingress 资源中定义多个 backend 或使用 canary 注解实现蓝绿切换。这种方式比 Service Selector 更灵活，支持基于权重、Header、Cookie 的灰度引流。

实现方式一：直接修改 backend

# 蓝环境 Service
apiVersion: v1
kind: Service
metadata:
  name: myapp-blue
spec:
  selector:
    app: myapp
    version: blue
  ports:
    - port: 80

# 绿环境 Service
apiVersion: v1
kind: Service
metadata:
  name: myapp-green
spec:
  selector:
    app: myapp
    version: green
  ports:
    - port: 80

# Ingress 指向蓝环境
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-blue    # 切换时改为 myapp-green
                port:
                  number: 80

实现方式二：基于权重的 Canary 切换（Nginx Ingress 示例）

# 主 Ingress（蓝环境）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-blue
                port:
                  number: 80
---
# Canary Ingress（绿环境，逐步引流）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"   # 10% 流量到绿环境
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-green
                port:
                  number: 80

优缺点对比

4.3 通过 Service Mesh 切换

Service Mesh（如 Istio、Linkerd、Consul Connect）将流量治理从基础设施层抽象到 Sidecar 代理层，提供最精细的蓝绿发布控制。通过定义 VirtualService 和 DestinationRule，可以实现基于权重、请求属性、故障注入的复杂路由策略，且切换过程完全无感于应用代码。

Istio 实现蓝绿发布示例

# 定义两个版本的子集
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp-destination
spec:
  host: myapp-svc
  subsets:
    - name: v1
      labels:
        version: blue
    - name: v2
      labels:
        version: green
---
# 路由规则：100% 流量到 v1（蓝环境）
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
    - myapp-svc
  http:
    - route:
        - destination:
            host: myapp-svc
            subset: v1
          weight: 100
        - destination:
            host: myapp-svc
            subset: v2
          weight: 0    # 切换时改为 100

Service Mesh 切换的独特优势

• 细粒度流量拆分：支持 1% 步进的权重调整，适合金丝雀发布。
• 请求级路由：基于 Header、Cookie、URI 参数将特定用户引流到绿环境。
• 故障注入与重试：可在切换前注入延迟或错误，验证新版本的容错能力。
• 可观测性：Sidecar 自动生成分布式追踪指标（请求量、延迟、错误率），便于切换决策。
• 零信任安全：mTLS 加密蓝绿环境之间的通信，避免数据泄露。

优缺点对比

三种实现方式对比总览

三种实现方式的架构对比图

选型建议

• 初创团队 / 小型集群：优先使用 Service Selector，零额外组件，切换逻辑直观，配合 Readiness Probe 即可满足基本蓝绿发布需求。
• 中大型集群 / 需要灰度发布：选择 Ingress 路由，利用 canary 权重逐步放量，结合 Prometheus 监控指标决定是否全量切换。
• 微服务架构 / 多团队协作 / 高安全要求：采用 Service Mesh，虽然运维成本高，但提供最完整的流量治理、可观测性和安全能力，适合长期演进。