引言

滚动更新（Rolling Update）是云原生应用实现零宕机部署的关键策略，广泛应用于Kubernetes等容器编排平台。运维人员需掌握更新策略配置、健康检查探针、Pod干扰预算（PDB）等核心机制，才能保障业务在迭代过程中的连续性与稳定性。本文梳理滚动更新运维的六大要点，帮助团队规避常见陷阱，提升发布效率。

滚动更新的基本原理与价值

滚动更新通过逐步替换旧版本Pod为新版本Pod，实现服务不中断升级。Kuberentes默认策略为逐步扩缩：先启动新Pod，待其就绪后再终止同等数量的旧Pod。此举可降低资源波动，适用于无状态应用及部分有状态场景。

关键运维要点

1. 合理配置更新策略

在Deployment或StatefulSet的.spec.strategy.rollingUpdate中设置两个关键参数：maxSurge（更新过程中超出期望副本数的最大Pod数，默认25%）和maxUnavailable（更新期间允许不可用的Pod数量，默认25%）。生产环境建议根据集群资源和服务重要性调整，例如maxSurge: 1、maxUnavailable: 0，确保每次仅新增一个Pod，且不中断现有服务。

2. 定义精准的健康检查探针

探针是滚动更新正确性的核心保障。需配置三种探针：

• livenessProbe：检测容器是否存活，失败则重启Pod。
• readinessProbe：检测容器是否准备好接收流量，失败则从Service Endpoints中移除。
• startupProbe：适用于启动慢的应用，避免liveness过早干预。

务必在readinessProbe中设置合理的初始延迟（initialDelaySeconds）和失败阈值（failureThreshold），防止刚启动的Pod被过早标记为就绪。

3. 设置Pod Disruption Budget保障可用性

PDB（Pod Disruption Budget）可限制自愿中断（如滚动更新、节点维护）对Pod数量的影响。例如：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

该PDB保证更新过程中始终至少有两个带有标签app: my-app的Pod可用。

4. 监控与告警机制

滚动更新期间需关注以下指标：

• Pod启动时间、重启次数
• 应用错误率（5XX状态码）
• 响应延迟变化
• 资源使用率（CPU/内存）

建议结合Prometheus和Grafana设置告警规则，当readiness探针失败超过阈值或错误率飙升时及时触发回滚。

5. 灰度发布与分阶段验证

对于核心业务，可采用灰度策略：先在小比例Pod上部署新版本，观察稳定后再全量更新。Kubernetes本身支持通过调整maxSurge和maxUnavailable实现简单灰度，更复杂的场景可借助Argo Rollouts或Flagger等工具实现金丝雀发布（Canary Release）和蓝绿部署（Blue-Green Deployment）。

6. 回滚策略与版本管理

滚动更新默认保留历史版本记录（.spec.revisionHistoryLimit，默认10）。当新版本出现严重故障时，使用kubectl rollout undo deployment/my-app快速回滚。运维应定期清理旧版本以避免存储膨胀，并保留关键版本的镜像标签和部署配置快照。

常见陷阱与最佳实践

• 探针设置过于宽松：导致有问题的Pod接管流量，引发雪崩。建议结合业务启动耗时调优探针参数。
• 忽视PDB：没有PDB时，滚动更新可能一次性停掉过多Pod，造成服务降级。
• 资源限制不足：新Pod启动可能因资源不足被Pending，拖慢更新进度。可预留集群余量或使用弹性伸缩。
• 日志与链路追踪：在滚动更新期间分布式追踪能够帮助快速定位新旧版本切换带来的请求错误。

遵循上述要点，团队可构建稳健的滚动更新流程，确保云原生应用在快速迭代中保持高可用与一致性。