Kubernetes的滚动更新（Rolling Update）是一种在不中断服务的情况下逐步替换Pod的部署策略，通过分批替换旧版本实例实现平滑升级。
一、滚动更新基本原理
滚动更新的核心在于渐进式替换，通过Deployment控制器协调新旧ReplicaSet的交替更新，确保服务连续性：
- 分批替换：逐个或按比例替换旧Pod，而非一次性全量更新。
- 新旧共存：更新期间新旧Pod短暂共存，流量逐步迁移到新Pod。
- 健康检查：新Pod必须通过
readinessProbe和livenessProbe检测才会继续替换，否则暂停更新。若不配置健康检查，则默认启动就是健康。
二、关键配置参数
滚动更新通过以下参数控制更新速度和稳定性：
-
maxSurge
• 定义允许超过期望副本数的最大Pod数量（绝对值或百分比）。 • 作用：加速更新，允许同时创建更多新Pod。 • 示例：若replicas=5且maxSurge=20%，则最多可同时运行6个Pod（5+1）。 -
maxUnavailable
• 定义允许不可用的旧Pod数量（绝对值或百分比）。 • 作用：限制更新期间服务可用性的下限。 • 示例：若replicas=5且maxUnavailable=20%，则至少保持4个Pod可用。
三、滚动更新策略类型
根据参数组合，常见策略分为三类：
| 策略类型 | 参数配置 | 特点 |
|---|---|---|
| 默认策略 | maxSurge=25%, maxUnavailable=25%或者maxSurge=1, maxUnavailable=1 | 平衡速度与稳定性，适用于大多数场景（如电商、金融）。 |
| 激进策略 | maxSurge=50%, maxUnavailable=50% | 快速更新，适用于非核心业务或测试环境，但可能短暂影响服务可用性。 |
| 保守策略 | maxSurge=0, maxUnavailable=1 | 严格限制不可用Pod数量，适用于对稳定性要求极高的场景（如支付系统）。 |
四、案例说明
maxSurge为1，maxUnavailable为1的配置如下
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 允许新增1个Pod
maxUnavailable: 1 # 允许1个旧Pod不可用
过程说明
步骤 1：创建第1个新Pod，并终止第1个旧Pod
-
创建新Pod：Kubernetes立即创建 1个新Pod（利用
maxSurge=1的额度）。 -
终止旧Pod：同时终止1个旧Pod（利用
maxUnavailable=1的额度）。 -
当前状态：
- 运行中的Pod总数：
4（原副本） + 1（新增） - 1（终止） = 4。 - Pod分布：3个旧Pod + 1个新Pod。
- 运行中的Pod总数：
步骤 2：创建第2个新Pod，并终止第2个旧Pod
-
创建新Pod：当新Pod就绪后，再创建 1个新Pod（再次利用
maxSurge=1的额度）。 -
终止旧Pod：同时终止 1个旧Pod。
-
当前状态：
- 运行中的Pod总数：
3旧 + 1新 + 1新（新增） - 1旧（终止） = 4。 - Pod分布：2个旧Pod + 2个新Pod。
- 运行中的Pod总数：
步骤 3：重复替换，直至完成
- 每次循环中，创建 1个新Pod 并终止 1个旧Pod。
- 最终所有旧Pod被替换为新Pod。
总结
Kubernetes滚动更新通过Deployment控制器和健康检查机制实现了平滑升级，是保障服务高可用的核心工具。合理配置maxSurge和maxUnavailable、结合优雅停机与监控告警，能有效平衡更新速度与稳定性。实际应用中需根据业务场景选择策略，例如金融系统采用保守参数，而内部工具可偏向激进策略。
