3. Deployment 升级策略基础：Recreate、RollingUpdate、蓝绿部署、金丝雀发布与 A/B 测试

在 Kubernetes 生态中，Deployment 是最核心的工作负载控制器，其升级策略直接决定了应用变更时的可用性、风险暴露面与回滚速度。本章深入剖析五种主流升级策略的原理、适用场景与配置要点，为后续多集群准入控制联动打下坚实基础。

3.1 Recreate 策略：全量替换，停机升级

Recreate 策略是所有升级策略中最简单、最粗暴的一种。当 Deployment 更新时，它会先删除所有旧版本 Pod，待旧 Pod 完全终止后，再创建新版本 Pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-recreate
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    spec:
      containers:
      - name: app
        image: my-app:2.0.0

3.2 RollingUpdate 策略：渐进替换，保持可用

RollingUpdate 是 Kubernetes Deployment 的默认升级策略。它通过逐步替换旧 Pod 为新 Pod，确保在整个升级过程中始终有足够数量的 Pod 提供服务。

两个关键参数控制滚动节奏：

• maxUnavailable：升级过程中允许的最大不可用 Pod 数量（值或百分比）。
• maxSurge：升级过程中允许超出期望副本数的最大 Pod 数量（值或百分比）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-rolling
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: my-app:2.0.0

3.3 蓝绿部署：独立环境，瞬间切换

蓝绿部署并非 Kubernetes 原生策略，而是通过两套完全独立的 Deployment + Service 实现的发布模式。蓝环境（Blue）运行当前稳定版本，绿环境（Green）部署新版本。验证通过后，通过修改 Service 的 selector 将流量瞬间从蓝切到绿。

3.4 金丝雀发布：小比例验证，渐进放量

金丝雀发布通过路由权重控制，将小部分流量（如 5%-10%）导向新版本，在真实生产流量中验证新版本的稳定性与性能。验证通过后逐步增加权重，直至全量切换。

在 Kubernetes 中，金丝雀发布通常借助 Service Mesh（如 Istio）、Ingress Controller（如 Nginx Ingress） 或 Flagger 等工具实现精细化的流量分割。

3.5 A/B 测试：基于特征的流量路由

A/B 测试与金丝雀发布的本质区别在于：金丝雀发布关注版本稳定性，而 A/B 测试关注业务效果对比。A/B 测试根据用户特征（如地域、浏览器、用户 ID 哈希、Cookie）将流量路由到不同版本，用于验证新功能对业务指标（转化率、点击率）的影响。

在 Kubernetes 中，A/B 测试通常需要 Istio VirtualService 或 自定义 Ingress 规则 实现基于 HTTP Header 或 Cookie 的路由。

# Istio VirtualService 示例：基于 Header 的 A/B 路由
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-ab
spec:
  hosts:
  - my-app.example.com
  http:
  - match:
    - headers:
        user-group:
          exact: "beta"
    route:
    - destination:
        host: my-app
        subset: v2
  - route:
    - destination:
        host: my-app
        subset: v1

3.6 策略对比与选型矩阵