滚动

maxSurge 与 maxUnavailable 两个窗口，给一次发布过程中最多能多出或缺少的 Pod 数定了上限,让升级始终在容量可控的前提下进行。 一次只换一小批 滚动更新不会把整份负载一次换掉,而是一批一批地先起新、再撤旧,并且整条链路都尊重 readiness。控制器会等新的 Pod 变就绪,才认为这次发布往前挪了一步,于是那些始终就绪不了的 Pod 会卡住这次发布,而不是偷偷用坏版本扛流量。这正是旧行为:任何时刻都不会从旧版一步跨到新版、中间一刻也没有空窗。因为切换被 readiness 拦住,你会在第一批新 Pod 就发现问题、中断发布,而不是等全量上线才知道砸了。 用 surge 与 drain 两扇窗 maxSurge 与 maxUnavailable 两扇窗,规定了整个发布的形状。maxSurge 允许多少个高于期望的额外 Pod,用于边排旧边补新;maxUnavailable 允许替换期间低于期望多少个。它们一组合,既定速度也定余量:surge 给得多就跑得快,代价是要有抵抗它的容量;而 maxUnavailable:1 + maxSurge:0 则偏向容量不动,却慢,并且发布窗口可以拉得很长。挑这两扇窗,看的应该是「如果这次发坏了我能容忍多坏」,而不是挑一组看起来左右均衡的数字,因为它们字面上就限定了这次发布能触碰多少 Pod。 回滚只是重新部署 因为一次发布本身只是另一张 spec,回滚不过是把镜像指回上一次跑的那份,然后同样受 readiness 约束的批次扰动,倒着再来一遍。把上一个版本保留着、随时能起,并优先用一个你读过、测过的旧镜像,而不是现场打的补丁——这样回滚路径本身就是一条被测试过的路径。审计一致、Pod 更替受同样的窗口约束,而团队也确切知道「回滚」是什么意思,它就是一次对最后已知好版本的重新部署,没有任何别的。 先选形状，再调节奏 strategy.type 只有两个值,而默认值把这个选择藏了起来。RollingUpdate 让新旧 Pod 在 surge 与 unavailable 两扇窗里重叠;Recreate 先把旧 Pod 删光,再建新 Pod,最小可用数按构造就是零,两扇窗直接被忽略。当两个版本绝不能并存,就选 Recreate:旧代码读不回去的单写迁移、排他文件锁或单例 worker、新旧互不兼容的有线协议。姊妹篇调的是波次节奏,这篇定的是发布形状。无状态层默认 RollingUpdate;一旦选了 Recreate,就要把停机排进计划,而不是等它找上门:测一次冷启动、预拉镜像、提前公告窗口。选之前先答三问:两个版本能同时 serving 吗,旧版本占着新版本要独占的资源吗,停机窗口能量化吗。第一问答否,直接 Recreate;第二问答是也倾向 Recreate,比如旧 Pod 占着的 hostPort 或 ReadWriteOnce 卷,新 Pod 根本起不来;第三问答否,说明还没测冷启动,先测再选。 ...