K8s Deployment 升级策略

Kubernetes Deployment 升级策略详解：生产环境实战指南

在 Kubernetes 中，Deployment 是管理无状态应用的核心对象，其升级策略直接影响服务可用性和发布效率。以下是生产环境中常用的 Deployment 升级策略及最佳实践，结合官方文档与实战经验整理。

---

一、原生支持的默认策略

Kubernetes 原生支持两种策略，通过 spec.strategy.type 定义：

1. 滚动更新（RollingUpdate，默认策略）
   核心目标：零停机升级。
   原理：逐步替换旧 Pod，同时确保一定比例的副本可用。
   关键参数：

   strategy:
     type: RollingUpdate
     rollingUpdate:
       maxUnavailable: 25%  # 允许同时不可用的 Pod 比例/数量
       maxSurge: 25%       # 允许超出期望副本数的 Pod 比例/数量
   

   • 适用场景：生产环境主流选择，适用于对稳定性要求高的服务。
   • 优势：平滑过渡，服务流量无感知。
   • 风险：新旧版本短暂共存，需确保版本兼容性。

2. 重新创建（Recreate）
   核心目标：快速全量替换。
   原理：先终止所有旧 Pod，再创建新 Pod。
   配置示例：

   strategy:
     type: Recreate
   

   • 适用场景：开发环境、单副本应用或无需零停机的场景。
   • 风险：服务短暂不可用，不适用于高可用架构。

---

二、扩展策略（需结合工具或自定义实现）

以下策略需借助 Ingress 控制器、Service Mesh 或第三方工具（如 Argo Rollouts、Flagger）：

3. 蓝绿部署（Blue/Green）
   原理：同时运行新旧两套环境，通过流量切换实现瞬间迁移。
   实现步骤：

   • 部署新版本（Green）并验证。
   • 修改 Service 的 selector 切换流量到 Green 环境。
     优势：回滚极快（切回旧标签即可）。
     缺点：资源占用翻倍，需提前规划集群容量。

4. 金丝雀发布（Canary）
   原理：将部分流量导入新版本，逐步验证稳定性。
   实现方式：

   • 通过 Kubernetes Service 的权重分配（如 Istio 的 VirtualService）。
   • 结合监控指标（如错误率、延迟）自动决定是否全量发布。
     适用场景：关键业务灰度验证，降低全量风险。

5. 影子部署（Shadow）
   原理：复制生产流量到新版本，但不影响实际用户。
   用途：性能压测或功能验证，尤其适用于金融、电商等高敏感场景。

---

三、生产环境最佳实践

1. 升级前准备

   • 版本兼容性：确保新版本兼容旧版数据格式和 API。
   • 预发布测试：在非生产环境验证镜像和配置（如使用 kubectl set image --dry-run）。

2. 监控与回滚

   • 健康检查：配置 livenessProbe 和 readinessProbe 避免不健康 Pod 上线。
   • 快速回滚：通过 kubectl rollout undo deployment/<name> 回退到上一版本。

3. 高级控制

   • 暂停与恢复：使用 kubectl rollout pause/resume 分阶段发布。
   • 版本历史保留：设置 revisionHistoryLimit 保留旧 ReplicaSet 用于回滚。

---

四、配置示例与命令

# 滚动更新配置示例
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # 每次最多1个Pod不可用
      maxSurge: 1       # 每次最多新增1个Pod

常用命令：

• 触发升级：kubectl set image deployment/<name> nginx=nginx:1.25
• 查看状态：kubectl rollout status deployment/<name>
• 回滚：kubectl rollout undo deployment/<name> --to-revision=2

---

五、总结

选择合适的升级策略需权衡业务需求与基础设施能力：

• 滚动更新：平衡稳定性和效率，适合大多数场景。
• 蓝绿/金丝雀：需额外工具支持，适合复杂业务验证。
• Recreate：简单粗暴，仅限非关键场景。

结合监控、自动化测试和渐进式发布，才能最大限度降低发布风险。

---

参考资料：
Kubernetes 官方文档
蓝绿部署与金丝雀发布实现原理
生产环境升级与回滚最佳实践