背景

滚动更新不是旧副本换成新副本这么简单：流量、节点余量和连接排空都会影响中间阶段的可用容量。

核心判断

  1. 用可承受的容量下降确定 maxUnavailable，用节点余量确定 maxSurge。
  2. 就绪时间、minReadySeconds 与退出宽限期一起评估。
  3. 保留版本级别的成功率和延迟指标，异常时暂停发布。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

strategy:
  type: RollingUpdate
  rollingUpdate: { maxUnavailable: 1, maxSurge: 1 }
replicas: 4

边界与误区

副本数并不等于有效处理能力，新副本未预热时不能立即承担峰值流量。终止中的 Pod 仍可能占用资源，预算不能只按理想副本数计算。

验证方式

在接近峰值的负载下发布，检查待调度 Pod、就绪时间和错误率。节点余量不足时验证发布如何停住，以及回滚是否仍有资源可用。

小结

根据最低服务容量计算 maxUnavailable 和 maxSurge，而不是照抄默认值。