一句话定义：滚动更新（Rolling Update）是一种发布方式：系统用新版本的实例逐个（或小批量）替换旧版本实例，整个过程中始终有实例在对外服务，用户通常感觉不到“发版”这件事。
它怎么转起来的
以 Kubernetes 为例：你声明“我要 10 个副本跑 v2 镜像”，控制器不会一次性把 10 个旧实例全删掉，而是新建一两个新实例，等它们就绪之后，再下线一两个旧实例，如此循环，直到全部换完。控制节奏的是两个参数：maxSurge（最多能多出几个实例）和 maxUnavailable（最多能少几个可用实例）。把 maxUnavailable 设为 0，理论上就能做到容量不掉。
这里的“就绪”不是“进程起来了”，而是 readinessProbe（就绪探针） 通过：容器按你配置的方式（HTTP 请求某个路径、执行命令、开 TCP 端口）被反复检查，返回成功才算就绪，才被加入负载均衡、才允许控制器继续往下滚。
打个比方：餐厅要换掉后厨的灶台。经理不会让所有厨师同时停工，而是先让一位新厨师上灶试做，试做合格才让一位老厨师下班。关键是“合格”的标准由你定——如果考核只问一句“你人在不在”，那新厨师哪怕不会做菜也能上岗，最后就是一批批不合格的人被换进后厨，客人吃到的全是生的。
和相邻概念的区别
| 方式 | 怎么换 | 资源开销 | 出问题时 |
|---|---|---|---|
| 重建（Recreate） | 先全停，再全起 | 低 | 服务直接中断 |
| 滚动更新（Rolling Update） | 逐个换，边换边服务 | 中（需额外实例） | 坏实例会按批次进入线上 |
| 蓝绿部署（Blue-Green） | 两套环境并行，切流量 | 高（双倍资源） | 切回去即可，影响面小 |
| 金丝雀发布（Canary） | 先给极小比例流量试水 | 中 | 只影响少量用户 |
还要区分三种探针：livenessProbe（存活探针）不通过会重启容器；readinessProbe 不通过只是摘掉流量、暂停滚动；startupProbe（启动探针）给启动慢的应用一段宽限期，避免还没起完就被判死。
对从业者的实际意义
滚动更新最容易被误解的一点是：它默认“新版本是好的”，只负责控制替换节奏。它判断“能不能继续往下滚”，几乎完全依赖 readinessProbe。探针写错，平滑发布就变成了分批把坏实例滚上线：
- 端口或路径写错，探针永远失败 → 发布卡住不动，看着像“卡住”，实际是保护机制生效了；
- 探针只检查
/health返回 200，而这个接口不看数据库连接、不看待加载的模型权重 → 实例“就绪”了但答不了请求； - 没有 startupProbe，模型加载要几分钟，存活探针提前判死 → 容器反复重启，滚动永远走不完；
- 探针超时和重试次数设置得太宽松，坏实例也能通过检查。
所以实践上的做法是：让就绪探针检查真正决定“能不能接客”的关键依赖（下游服务、缓存、模型是否已加载），给慢启动服务配 startupProbe，把 maxUnavailable 调小并保留历史版本以便回滚，发布期间盯住错误率和延迟而不是只盯“发布成功”。另外，滚动更新不提供按用户比例分流的能力，真要小流量验证，还得配合金丝雀或服务网格。各平台的具体参数名和默认值有差异，以官方文档为准。