Kubernetes 中的滚动发布（Rolling Update）是一种非常优雅的部署策略，它能让你在更新应用时，实现零停机 和用户无感知的平滑升级。下面这张图清晰地展示了它的核心工作流程：
下面，我们详细解读这个过程，并看看如何掌控它。
🔄 滚动发布如何工作
滚动发布的核心思想是逐步替换。它不是一次性停止所有旧版本的 Pod（实例），然后再启动所有新版本的 Pod。相反，它遵循一个精心控制的流程：
- 逐步更替 ：如流程图所示，系统会先启动一个新版本 Pod （V2），并等待其通过就绪探针检查，确认其已准备好接收流量。
- 流量切换 ：一旦新的 Pod 就绪，负载均衡器（通常是 Kubernetes Service）就会将流量引导到它上面，同时终止一个旧版本 Pod（V1）。
- 循环往复：这个过程循环进行，直到所有旧版本的 Pod 都被替换为新版本的 Pod。
这种方式确保了在整个更新过程中，始终有可用的 Pod 实例在对外提供服务，从而实现了零停机。
⚙️ 核心配置参数
滚动发布的精细控制，主要通过 Deployment 配置中的 strategy.rollingUpdate下的两个关键参数实现：
| 参数 | 作用 | 默认值 | 生产环境建议 |
|---|---|---|---|
**maxSurge** |
控制最多能创建多少个超出期望副本数的 Pod。 | 25% | 通常设置为 1 或 25%。这相当于更新过程中的"缓冲区"，允许新 Pod 提前启动。 |
**maxUnavailable** |
控制在更新过程中，最多允许多少个 Pod 不可用。 | 25% | 对于要求高可用的服务，可设置为 0，确保更新期间服务容量不降低。 |
举个例子 ：如果你的应用有 4 个副本，并设置 maxSurge=1（最多可超 1 个 Pod），maxUnavailable=0（不允许任何 Pod 不可用）。那么滚动更新时，Kubernetes 会先创建一个新 Pod（此时总数为 5 个），待其就绪后，再终止一个旧 Pod（总数恢复 4 个），如此循环。这样，任何时候都至少有 4 个 Pod 是可用的。
🛠️ 实战操作指南
掌握了原理后，你可以通过以下命令来管理和监控滚动发布：
| 命令 | 功能 |
|---|---|
kubectl set image deployment/<部署名称> <容器名>=<新镜像>:<标签> |
触发更新。这是最常用的触发方式。 |
kubectl rollout status deployment/<部署名称> |
实时查看更新状态和进度。 |
kubectl rollout pause deployment/<部署名称> |
暂停滚动更新。适用于想在某个中间状态进行验证的场景。 |
kubectl rollout resume deployment/<部署名称> |
继续被暂停的滚动更新。 |
kubectl rollout undo deployment/<部署名称> |
回滚到上一个版本。这是滚动发布带来的巨大优势之一。 |
kubectl get pods -w |
观察 Pod 的新旧替换过程，直观看到流程图中的每一步。 |
💡 确保平滑发布的进阶技巧
要让滚动发布真正丝滑，还需要注意以下几点：
- 配置就绪探针 ：这是最重要的配置！
readinessProbe告诉 Kubernetes 你的应用何时真正准备好接收流量。如果没有它，Kubernetes 会在容器进程启动后立即发送流量，而此时你的应用（如 Spring Boot 项目）可能还在加载 Spring 上下文或连接数据库，导致请求失败。务必根据应用启动特点配置合理的路径和延迟时间。 - 配置优雅终止 ：在 Pod 被终止时，Kubernetes 会向容器内的进程发送 SIGTERM 信号。你的应用应该捕获这个信号，然后停止接收新请求，并等待已有请求处理完成后再退出。这可以通过在 Deployment 中配置
spec.template.spec.terminationGracePeriodSeconds并结合preStop钩子来实现，给应用一个清理和退出的缓冲时间。 - 避免使用
latest标签 ：在 Deployment 的 YAML 中，明确指定镜像版本标签。使用latest标签会导致无法清晰追踪当前运行的版本，也给回滚带来不确定性。
⚖️ 优缺点与策略对比
| 特点 | 滚动发布 | 重建发布 | 蓝绿发布 |
|---|---|---|---|
| 发布方式 | 逐步替换，新老版本同时存在一段时间 | 先全部停止旧版本，再启动新版本 | 部署两套完整环境，流量一次性切换 |
| 资源占用 | 低（只需运行一套环境） | 低（只需运行一套环境） | 高（需要两套环境的资源） |
| 发布风险 | 中（风险被分散，可快速回滚） | 高（服务有中断期） | 低（回滚极快） |
| 复杂度 | 低（Kubernetes 原生支持） | 低 | 中（需要额外的流量控制能力） |
💎 总结
总而言之，Kubernetes 的滚动发布是一种强大且实用的部署策略。理解其逐步替换 的工作原理，熟练运用 maxSurge和 maxUnavailable 来控制节奏，并结合就绪探针和优雅终止等最佳实践，你就能真正掌握在 Kubernetes 上进行平滑、无损应用发布的艺术。