Kubernetes滚动更新怎么做？发布、回滚与灰度升级思路

一、Kubernetes滚动更新是什么

滚动更新是 Deployment 默认支持的一种更新策略。当应用镜像版本、环境变量或模板配置发生变化时，Deployment 会逐步创建新 Pod，并逐步减少旧 Pod。

它不会一次性停止全部旧实例，而是按一定节奏完成替换，从而降低发布过程中服务不可用的风险。

简单来说：

• 先启动一部分新版本 Pod
• 等新 Pod 就绪后，再减少部分旧 Pod
• 持续循环，直到全部替换完成

二、为什么需要滚动更新

传统发布方式如果先停旧版本再启动新版本，很容易出现服务中断。滚动更新的价值在于：

• 降低发布中断风险
• 支持应用平滑升级
• 可以逐步观察新版本状态
• 出现问题时更容易回滚
• 适合多副本微服务应用

对于需要持续交付的团队来说，滚动更新是最基础的发布能力。

三、Deployment如何控制滚动更新

Deployment 通过更新 Pod 模板触发滚动更新，例如镜像版本从 v1 改为 v2。

过程中涉及两个关键参数：

• maxUnavailable：更新过程中最多允许多少副本不可用
• maxSurge：更新过程中最多可以额外创建多少副本

这两个参数会影响发布速度和服务可用性。如果业务对稳定性要求高，可以让更新更保守；如果希望快速发布，可以适当提高更新速度。

四、健康检查为什么很重要

滚动更新能否安全进行，很大程度取决于健康检查是否可靠。Kubernetes 常用探针包括：

• readinessProbe：判断 Pod 是否可以接收流量
• livenessProbe：判断容器是否需要重启
• startupProbe：判断慢启动应用是否已经启动完成

如果 readinessProbe 配置不合理，新版本 Pod 还没真正准备好就接收流量，可能导致用户请求失败。因此发布前要确保健康检查能真实反映应用状态。

图1：Kubernetes部署流程示意图

五、如何做发布回滚

当新版本出现异常时，可以通过 Deployment 的历史版本进行回滚。回滚的本质是把 Pod 模板恢复到之前版本，再触发一次更新。

回滚策略要关注：

• 镜像版本是否可追踪
• 配置变更是否可回退
• 数据库变更是否兼容
• 发布记录是否清晰
• 是否有监控和告警触发回滚决策

注意，Kubernetes 可以回滚工作负载配置，但不能自动解决所有业务兼容问题。数据库变更、配置变更和依赖变更仍需要单独设计。

图1：Kubernetes部署流程示意图

六、滚动更新和灰度发布有什么区别

滚动更新主要是逐步替换实例，它更关注部署过程平滑。

灰度发布更关注流量控制，通常希望先让少量用户或少量流量访问新版本，再逐步扩大范围。

可以简单理解为：

• 滚动更新：按实例逐步替换
• 灰度发布：按流量或用户范围逐步放量

在更复杂的场景中，灰度发布可能需要配合 Ingress、服务网格或发布平台实现。

七、生产环境滚动更新注意事项

生产环境使用滚动更新时，需要注意：

• 应用必须支持多副本运行
• 新旧版本最好保持接口兼容
• readinessProbe 要配置准确
• 镜像版本不能只用 latest
• 发布前后要观察错误率和延迟
• 关键服务要准备回滚方案

滚动更新不是万能保险，真正安全的发布还需要监控、告警、版本管理和变更规范配合。