Kubernetes 滚动发布用可用副本约束替换速度

Kubernetes Deployment 把应用版本更新描述为期望状态变化。控制器创建新的 ReplicaSet，逐步增加新 Pod 并减少旧 Pod，直到新模板接管所需副本。滚动发布解决的是工作负载替换过程，不自动证明新版本在业务上正确。

一次可靠发布需要把副本预算、就绪判定、容量、兼容性和回滚证据放在一起。只执行镜像更新并等待命令显示完成，可能在所有 Pod 都“就绪”后才发现错误数据或关键流程失败。

Deployment 修订来自 Pod 模板变化

Deployment 管理 ReplicaSet，ReplicaSet 再维持 Pod 数量。修改 Pod 模板中的镜像、环境、标签或其他字段会触发新修订；单纯调整副本数通常不会创建同类修订。理解这一点有助于判断回滚到底能恢复什么。

控制器比较声明状态与当前状态并持续协调。人工删除新 Pod不会撤销发布，ReplicaSet 会重新创建。若需要停止推进，应暂停 Deployment 或回滚模板，而不是与控制器争抢单个 Pod。

修订历史主要保存 Pod 模板，不包含数据库迁移、外部配置和手工操作。回滚 Deployment 不能自动撤销已经写入的数据，也不能恢复被覆盖的外部依赖。因此应用发布必须提前设计向前和向后兼容。

maxUnavailable 限制更新过程中最多有多少期望副本不可用，maxSurge 允许临时创建多少额外副本。前者保护服务容量，后者决定额外资源需求。两者都可用绝对数或百分比表达，并受取整规则影响。

将不可用设得很低可以保留容量，却会让发布更慢；允许较大 surge 可以加速，但集群必须有足够 CPU、内存、IP、存储和下游连接。若资源配额只够原副本，新 Pod 无法调度，滚动过程就可能停滞。

副本数很小时，百分比配置尤其要检查实际换算。两个副本的服务和两百个副本的服务不能只复制同一百分比。还要考虑一个副本退出和新副本启动期间，负载是否会集中到剩余实例。

readiness probe 失败的 Pod 不应进入服务就绪端点，滚动控制器也会据此计算可用副本。检查应覆盖进程真正服务请求所需的关键条件，但不宜依赖每个远程系统都完全健康，否则共享依赖抖动会同时摘除所有实例。

startup probe 可以给慢启动应用独立窗口，避免 liveness probe 在初始化完成前反复重启。liveness 适合发现无法自行恢复的进程卡死，不应把普通下游超时当作重启理由。三类探针解决的问题不同。

应用宣告就绪前，应完成本地缓存、连接池和必要资源加载；退出时要先停止接收新流量，再等待进行中请求结束。终止宽限期、生命周期钩子和负载均衡端点更新存在时间差，需要用真实长请求验证。

Deployment 可报告 progressing、available 等状态，并通过进度期限标记长期停滞。常见停滞原因包括镜像拉取失败、启动崩溃、探针失败、资源不足和权限错误。自动化发布应读取状态和事件，而不是用固定睡眠时间猜测完成。

平台层完成后，还要检查业务信号：错误率、延迟、关键交易、队列积压和版本分布。新旧版本同时运行时，日志、指标和追踪必须带版本属性，才能识别只有新版本出现的问题。

金丝雀并不等同于把 rolling update 调慢。真正的金丝雀需要控制一小部分流量或实例、定义观察窗口与通过标准，并在扩大前比较基线。原生 Deployment 可以形成新旧副本并存，但精细流量分配通常还需要额外路由能力。

Kubernetes 可以把 Deployment 的 Pod 模板恢复到历史修订。回滚前应确认旧镜像仍可获取、旧配置仍有效、数据库模式向后兼容，并知道新版本是否已经写入旧版本无法读取的数据。

数据库迁移常采用扩展再收缩：先增加兼容字段和双读写能力，待所有实例升级、数据回填并验证后，再在后续发布移除旧结构。把破坏性迁移与应用更新绑在同一步，会让快速回滚失去作用。

外部消息格式、缓存键和任务负载也要兼容。滚动期间旧消费者与新生产者可能同时存在，消息契约必须支持混合版本。后台任务若被新旧实例重复领取，还需幂等和租约保证。

发布记录要包含镜像 digest、配置版本、Deployment 修订、变更单、开始结束时间和操作者。使用可变镜像标签会让同一模板在不同时间拉到不同内容，难以证明回滚恢复了哪个二进制。

发布前验证清单应覆盖资源余量、探针、Pod disruption budget、依赖配额和回滚条件。发布后保存新旧版本指标比较、异常事件和最终决定。失败发布也应保留，不要只记录成功结果。

Kubernetes 文档准确描述控制器行为，但具体默认值和特性会随版本变化，操作手册应标明集群版本。平台可以自动替换副本，发布责任仍在团队：知道何时继续、何时暂停，以及回滚能恢复哪些状态。