零停机部署与持续交付的终极指南
目录导读
- 什么是滚动更新方法？
- 滚动更新的核心原理与工作流程
- 滚动更新 vs 蓝绿部署 vs 金丝雀发布
- 主流平台（Kubernetes、Docker Swarm、AWS ECS）实践指南
- 关键参数配置：maxSurge 与 maxUnavailable
- 滚动更新中的回滚策略
- 常见问题与最佳实践
- Q&A：滚动更新方法深度问答
什么是滚动更新方法？
滚动更新（Rolling Update）是一种零停机部署策略，它通过逐步替换旧版本实例为新版本实例，确保应用程序在更新过程中始终保持可用状态，与传统的“停止所有旧版本→部署新版本”方式不同，滚动更新采用渐进式替换：一次只替换一小部分实例，直到所有实例均完成更新。
这种方法对于追求高可用性的生产环境至关重要,根据2024年CNCF的调查，超过78%的容器化生产环境采用滚动更新作为首选部署策略。
滚动更新的核心原理与工作流程
滚动更新的工作流程可以分为五个阶段：
健康检查就绪
- 在更新前,系统确认当前所有实例均处于健康状态（通过HTTP健康端点或gRPC探针）。
- 设定最低可用实例数（例如95%的副本必须持续响应）。
启动新版本实例
- 根据
maxSurge参数，系统同时启动一定数量的新版本实例（额外启动1个或25%的实例）。 - 新实例完成初始化并等待就绪探针确认。
流量切换
- 一旦新实例通过健康检查,负载均衡器开始将请求路由至新实例。
- 旧实例逐渐进入“终止前等待”状态（
terminationGracePeriodSeconds）。
缩容旧版本
- 根据
maxUnavailable参数，系统回收已确认健康的旧版本实例。 - 每次缩容量可控（每次仅销毁1个旧实例）。
迭代直至完成
- 重复阶段二至四,直到所有旧版本实例被替换。
- 过程中,可用实例总数始终维持在
replicas - maxUnavailable以上。
滚动更新 vs 蓝绿部署 vs 金丝雀发布
| 策略 | 切换速度 | 资源消耗 | 风险控制 | 适用场景 |
|---|---|---|---|---|
| 滚动更新 | 中等（逐步替换） | 低（共享资源） | 中等（逐步暴露） | 大多数Web服务、微服务 |
| 蓝绿部署 | 瞬间（环境切换） | 高（双倍资源） | 低（全量回滚） | 数据库迁移、核心API |
| 金丝雀发布 | 慢（逐步增加流量） | 低（部分流量） | 极低（小范围验证） | 关键业务功能、A/B测试 |
关键差异点：
- 滚动更新不需要额外的基础设施成本（无需维护两个完整环境）。
- 蓝绿部署适合需要“全或无”切换的场景，但资源消耗翻倍。
- 金丝雀发布最适合验证新版本行为,但更新周期较长。
主流平台实践指南
Kubernetes 滚动更新实现（YAML示例）
apiVersion: apps/v1
kind: Deployment
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # 最大不可用实例数（或百分比）
maxSurge: 2 # 最大超出目标数（实例数或百分比）
template:
spec:
containers:
- name: app
image: my-app:2.0.0
readinessProbe: # 关键：就绪探针确保新版本可用
httpGet:
path: /healthz
initialDelaySeconds: 10
periodSeconds: 5
Docker Swarm 滚动更新
# 逐步更新服务，每次更新2个副本 docker service update --update-parallelism 2 my-service
AWS ECS 滚动更新配置
在ECS任务定义中设置 deploymentConfiguration：
minimumHealthyPercent: 100
maximumPercent: 200（表示更新期间始终保留100%健康实例，最多可扩展至200%）
关键参数配置：maxSurge 与 maxUnavailable
maxUnavailable（默认值：25%）：
- 表示更新过程中允许的最大不可用实例比例。
- 值越小,容量冗余越高，但更新速度越慢。
- 生产环境中推荐设置为
1或10%。
maxSurge（默认值：25%）：
- 表示在更新期间,可以超出
replicas数量的最大实例数。 - 值越大,更新速度越快，但需要更多空闲资源。
- 对于资源紧张的环境,可设置为
0（但需配合maxUnavailable使用）。
经验公式：
- 稳定更新速度 =
maxSurge / (maxSurge + maxUnavailable) * 更新批次时间 maxSurge=2, maxUnavailable=1时，每10秒可替换2个实例（共10个副本需约50秒）。
滚动更新中的回滚策略
自动回滚触发条件：
- 新版本实例在就绪探针超时后仍未报告健康。
- 新实例连续启动失败次数超过
progressDeadlineSeconds（K8s默认10分钟）。 - 监控指标（如错误率上升超过5%）触发回滚。
手动回滚命令：
# Kubernetes kubectl rollout undo deployment/my-app # Docker Swarm docker service update --rollback my-service
回滚注意事项：
- 回滚操作本身也是滚动更新,需确保旧版本镜像仍可用。
- 数据库 schema 变更时，回滚需额外处理（建议先回退应用版本，再执行数据库迁移回滚）。
常见问题与最佳实践
问题1：更新过程中出现“CrashLoopBackOff”
- 原因：新版本存在致命错误，无法启动。
- 解决方案：检查就绪探针配置，确保
initialDelaySeconds足够长（建议≥10秒）。
问题2：更新速度太慢
- 常见瓶颈：
maxSurge设置过低或readinessProbe检测间隔过大。 - 优化：临时增加
maxSurge至50%，或在低峰期执行更新。
问题3：数据库连接错乱
- 原因：旧实例与新实例同时连接数据库，但 schema 不兼容。
- 最佳实践：采用“前向兼容”数据库迁移（如新增列且旧代码忽略未知列）。
最佳实践清单：
- 始终配置
readinessProbe和livenessProbe。 - 使用
progressDeadlineSeconds设置更新超时限制。 - 对于有状态应用（如消息队列消费者），增加
terminationGracePeriodSeconds（建议≥60秒）。 - 在CI/CD流程中添加自动化健康检查步骤（至少等待两次健康检查周期）。
- 监控更新过程的“滚动窗口”（如每10秒检查一次可用实例数）。
Q&A：滚动更新方法深度问答
Q1：滚动更新与灰度发布（金丝雀发布）的核心区别是什么？ A：滚动更新是自动化的实例置换过程，它将实例视为无差别单元；而灰度发布涉及流量分发权重的灵活控制（如10%流量导入新版本），并且通常需要对用户会话、缓存进行细粒度管理，实际生产中，两者常结合使用：先用金丝雀验证核心功能，确认无误后执行滚动更新完成全量部署。
Q2：当数据库 schema 变更时，滚动更新如何避免出错？ A：推荐“前向兼容”+“两阶段迁移”策略：
- 第一阶段：部署新应用（同时支持旧、新 schema），数据库新增列或表（旧代码忽略新增字段）。
- 第二阶段（所有实例更新后）：执行数据迁移，移除旧代码依赖的废弃字段。
- 回滚时：只需回退应用版本，数据库保持最新结构（旧版本忽略新增字段）。
Q3：如果滚动更新过程中节点资源不足怎么办？
A：maxSurge 会增加资源消耗，解决方案包括：
- 配置 PodDisruptionBudget（PDB）限制同时中断的 Pod 数量。
- 使用集群自动扩缩（Cluster Autoscaler）在资源紧张时自动添加节点。
- 将
maxUnavailable设为大于0，避免maxSurge触发资源争用。
Q4：Kubernetes 滚动更新中，新版本 Pod 就绪但流量未切换，可能是什么原因？ A：最常见的两个原因：
- 没有配置
readinessProbe（K8s默认认为Pod就绪，但Service可能未正确路由）。 - 存在
readinessGates条件未被满足（如自定义指标尚未符合要求），检查kubectl describe pod中的 Conditions 字段可排除问题。
Q5：如何实现指定版本的渐进式替换（如每次仅替换30%实例，然后评估运行状态）？
A：可以使用 Kubernetes 的 kubectl set image 配合 --record 生成历史，但更推荐使用 Argo Rollouts 或 Flagger 这类专门工具，Argo Rollouts 的 step 配置：
steps:
- setWeight: 30
pause: {duration: 5m}
- setWeight: 60
pause: {duration: 5m}
- setWeight: 100
这能确保每个阶段有足够的观察期,且可自动触发回滚。
标签： 滚动更新