首页/开发/CI/CD 与发布速查/maxSurge 与 maxUnavailable 调参
发布策略60 条

maxSurge 与 maxUnavailable 调参

两个字段决定滚动更新的并发度与可用容量下限:加大 maxSurge 更新更快但多占资源,maxUnavailable 决定更新期间可以损失多少容量。

CI/CD 与发布速查开发更新于 2026-10-13

两个参数决定什么

它们决定滚动更新的并发度与可用容量下限:maxSurge 是更新期间允许超出的 Pod 数(多建多少),maxUnavailable 是允许不可用的 Pod 数(可少多少)。加大 maxSurge 更新更快但多占资源;maxUnavailable 直接决定更新期间损失多少容量。取值可为绝对值或百分比(如 1、25%),两者默认均为 25%,且不能同时为 0,否则 Deployment 校验直接拒绝。

基本信息

取值绝对值或百分比(如 1、25%)
默认两者默认均为 25%
约束两者不能同时为 0
卡死兜底progressDeadlineSeconds 超时标记 ProgressDeadlineExceeded
保守起点容量敏感服务常用 maxSurge=1 配 maxUnavailable=0

典型使用场景

  • 容量敏感服务:maxUnavailable=0 保证容量不降,maxSurge=1 逐个替换。
  • 大副本服务提速:副本多时放宽 maxUnavailable,让替换更并行。
  • 资源紧张集群:maxSurge=0 不允许超额占用,用容量换资源。
  • 发布窗口紧:临时调大 maxSurge 加速,发布后恢复日常值。
  • 小副本服务:显式设置绝对值,避免百分比取整造成的意外损失。
  • 容量测算:按峰值流量推算最小副本数,反推两个参数的安全上限。

保守配置

保守配置
strategy:
  rollingUpdate:
    maxSurge: 1          # 每次多建 1 个新 Pod
    maxUnavailable: 0    # 更新期间不允许少实例
容量敏感服务常用 maxSurge=1 加 maxUnavailable=0:先扩后缩不降容量;副本多、追求速度时可放宽 maxUnavailable。
百分比按期望副本数计算并向下取整:副本少的时候 25% 的结果与直觉不符,重要服务建议用绝对值。
两个参数与就绪探针联动:新 Pod 未就绪不会缩旧 Pod,探针配置会间接影响发布速度。

参数组合对照

组合效果适用
激增大、不可用小快且容量稳节点余量充足
激增小、不可用为零稳但慢容量敏感的在线服务
激增为零、不可用大于零不占额外资源资源紧张优先保容量之外
双高最快但风险大内部低风险服务
参数与副本数联动评估:副本越多,同样的百分比允许的不可用实例越多,先算绝对值再决定是否用百分比。

易错点

  • 两字段同时为 0:Deployment 校验直接拒绝,更新无法进行。
  • 低副本数用默认 25%:向下取整后可能一次损失过多容量,容量直接腰斩。
  • maxUnavailable 调大但忽略流量峰值:低峰发布没问题,高峰期同样配置酿成事故,参数要按峰值容量设计。
  • maxSurge 太大而集群没有节点余量:新 Pod 排队等资源,更新反而更慢。
  • 参数只在临时改动里生效、没同步到模板:下次发布回到旧节奏,改动要落回仓库。
  • 只调参数不改探针与容量:参数只是节奏开关,容量与健康判定不达标时快慢都救不了发布。

数据来源与参考

  • Kubernetes 文档《Deployments》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌