在 Kubernetes 中，发布不是一次 kubectl apply，而是一场风险受控的工程行为。
真正成熟的团队，关注的不只是“如何升级成功”，而是：
- 升级过程中是否 不中断、不丢请求
- 新版本异常时能否 秒级止损
- 整个过程是否 可观测、可审计、可复盘
本文将从 滚动升级原理 → 参数调优 → 风控机制 → 回滚方案 → 监控与自动化 → 进阶发布策略 六个层面，系统性讲清 Kubernetes 的生产级发布与回滚体系。
一、滚动升级的本质：受控替换，而非简单重启
1.1 核心原理
Kubernetes Deployment 的默认更新策略是 RollingUpdate。其核心逻辑是：
在保证 Service 始终只把流量导向“可用 Pod”的前提下，逐步用新 Pod 替换旧 Pod。
关键点在于：
- Service 只转发流量给 readinessProbe 通过的 Pod
- 新旧 Pod 会在一段时间内 共存
- 升级过程中 不需要停机
二、滚动升级核心参数：理解“计算规则”比记参数更重要
滚动升级的行为完全由 Deployment 的几个参数决定。
2.1 核心参数与计算逻辑
| 参数 | 含义 | 默认行为 | 生产影响 |
|---|---|---|---|
maxSurge | 允许额外创建的 Pod 数 | 25%，向上取整 | 决定升级速度 |
maxUnavailable | 允许不可用的 Pod 数 | 25%，向上取整 | 决定可用性保障 |
minReadySeconds | Pod 就绪后的稳定时间 | 0 | 防止冷启动接流量 |
revisionHistoryLimit | 保留的历史版本数 | 10 | 影响回滚能力 |
progressDeadlineSeconds | 发布超时阈值 | 600s | 防止发布“卡死” |
示例
)
)
