在Kubernetes里干活久了你会发现Deployment几乎是每天都要打交道的对象。而Deployment的更新策略——Recreate和RollingUpdate这俩词儿看着简单真正用起来、踩过坑之后才知道里面门道不少。很多朋友面试时候被问到“Recreate和RollingUpdate有什么区别”张口就能说“一个是先删后建一个是滚动替换”但真到生产环境里配参数、排查更新卡住的问题时往往就抓瞎了。这篇博文就围绕这两种更新策略把原理、参数、实操、避坑一次讲透。文章主要适合这几类人看刚学k8s、准备考CKA或者面试运维岗的新手正在折腾集群升级、应用发版的在职运维和研发以及那些被“更新服务半天起不来”“滚动更新把节点打爆”这类问题折磨过的朋友。读完之后你不仅能分清两种策略的适用场景还能照着后面的实操步骤自己动手验证一遍顺便把maxSurge、maxUnavailable这些参数的计算逻辑彻底搞明白。1. 两种更新策略的整体设计与思路拆解1.1 先搞懂Deployment的底层工作机制聊更新策略之前得先把Deployment这个控制器的底细摸清楚。Deployment本身不直接管理Pod它管理的是ReplicaSet再由ReplicaSet去确保指定数量的Pod副本运行。整个链条是这样的Deployment -- ReplicaSet -- Pod你创建了一个Deployment声明replicas: 3Deployment控制器就会创建一个ReplicaSet这个ReplicaSet再去创建3个Pod。当你要更新Pod模板比如换镜像tag、改环境变量、调资源limitsDeployment不会直接去改正在运行的Pod而是用新模板创建一个新的ReplicaSet然后按照你配置的更新策略把流量和副本从旧ReplicaSet迁移到新ReplicaSet。我见过不少新手在这个地方犯迷糊以为Deployment更新就是改Pod其实改的是ReplicaSet。这个理解很重要因为两种更新策略的本质区别就是“新旧ReplicaSet之间如何交接”的问题。Recreate是先把旧ReplicaSet的Pod全删掉再让新ReplicaSet创建PodRollingUpdate则是让新旧两个ReplicaSet在同一个时间段里并存按照你指定的速率平滑切换。1.2 从设计哲学看Recreate和RollingUpdate为什么k8s要提供两种策略说白了就是两种完全不同的可用性诉求。Recreate的设计逻辑一致性优先可用性靠后。更新时先把所有旧版本Pod杀掉等全部终止了再创建新版本Pod。这个过程中服务会有一段真空期外部请求打过来就是连接拒绝或者超时。它的优点在于简单、干净同一时刻集群里只有一个版本的Pod在跑不会出现新旧版本并存导致的兼容性问题。典型场景就是那些有状态的服务、数据库迁移脚本、需要独占资源的批处理任务或者你明确知道新旧版本不能共存的应用。RollingUpdate的设计逻辑可用性优先平滑是关键。它不会一次性杀掉所有Pod而是分批替换始终保持有一部分Pod在提供服务。每启动一个或几个新Pod确认它Ready了再去干掉对应数量的旧Pod。这个过程的理想效果是“服务不中断”哪怕中间某个新Pod启动失败也能通过暂停更新来止损。Web服务、API网关、无状态应用基本都是这个策略。我个人的理解是Recreate是“快刀斩乱麻”RollingUpdate是“温水煮青蛙”。前者牺牲了可用性换来了过程的确定性后者牺牲了过程的绝对干净换来了服务的连续性。没有哪个绝对更好只有哪个更适合你的业务场景。1.3 选型之前先想清楚这几个问题判断该用哪个策略不用背八股文你就问自己几个问题新旧版本能同时对外提供服务吗数据库表结构变了、接口不兼容了、缓存key格式改了这些情况新旧版本共存大概率要出事老老实实用Recreate。服务中断几秒到几十秒能接受吗内部系统、离线任务、夜间批量任务中断一会儿问题不大Recreate省心。如果更新过程中出问题我能不能接受快速回滚RollingUpdate天然支持滚动回滚但回滚本身也是一次滚动更新还是需要时间Recreate的回滚则是再杀一遍再建一遍简单粗暴但中断时间更长。我的集群资源够不够RollingUpdate在更新高峰期会同时跑新旧两套Pod资源占用是replicas的1maxSurge倍。如果你的集群资源本来就紧张RollingUpdate可能直接把节点打爆这时候Recreate反而更安全。想清楚这几个问题策略选择基本上就不会跑偏了。2. 核心细节解析与实操要点2.1 Recreate策略的YAML写法与行为特征Recreate的配置非常简单不需要任何额外参数。在Deployment的spec里指定strategy.type: Recreate就行完整示例如下apiVersion: apps/v1 kind: Deployment metadata: name: web-server namespace: default spec: replicas: 3 strategy: type: Recreate selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80整个更新过程可以拆成三个阶段缩容到零Deployment控制器把旧ReplicaSet的spec.replicas直接从3改成0kubelet逐个终止旧Pod。注意这里有坑如果Pod里有preStop钩子它会先执行preStop里的命令等钩子执行完或者超时默认超时是terminationGracePeriodSeconds默认30秒才发SIGTERM。等待旧Pod完全终止控制器会盯着旧Pod的状态确认全部变成Terminated状态才会进入下一步。扩容新ReplicaSet创建新ReplicaSetspec.replicas设为3开始创建新Pod。所以Recreate的时间成本大概是“旧Pod终止耗时 新Pod启动耗时”。如果你的Pod终止很慢比如preStop里有清理动作、优雅退出逻辑这个中断窗口会被拉得很长。注意Recreate策略下如果Pod带有preStop钩子且逻辑耗时较长服务的不可用时间会显著增加。我在实际项目里见过一个Java应用preStop里要等线程池排空旧Pod拖了2分钟才退出整个更新期间服务完全不可用。这种情况要么优化钩子逻辑要么考虑RollingUpdatemaxUnavailable: 1。2.2 RollingUpdate策略的YAML写法与核心参数RollingUpdate配置相对复杂有两个核心参数maxSurge和maxUnavailable。完整示例如下apiVersion: apps/v1 kind: Deployment metadata: name: web-server namespace: default spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80这两个参数控制的其实是一个“可用Pod数量范围”的问题。replicas声明的是期望副本数但RollingUpdate允许在整个更新过程中实际可用的Pod数量在这个期望值附近波动。maxSurge定义了最多可以多出多少个PodmaxUnavailable定义了最多可以有多少个Pod处于不可用状态。参数可以写成百分比也可以写成整数。整数好理解就是字面意义的Pod数量百分比则是相对replicas的Round Up向上取整。比如replicas: 5maxSurge: 20%向上取整就是1maxUnavailable: 20%向上取整也是1。这里有个容易忽略的细节百分比计算还要考虑replicas是1的情况比如replicas: 1maxUnavailable: 50%向上取整后是1也就是说那个唯一的老Pod可以随时被干掉更新过程中可能出现“完全没Pod提供服务”的窗口。2.3 maxSurge与maxUnavailable的计算逻辑这个公式我必须拿出来单独讲因为它是整个RollingUpdate策略里最容易算错的地方。先看maxSurge和maxUnavailable的取值范围参数合法范围说明maxSurge0或正整数/百分比不能设置为0除非maxUnavailable也设置为0但那样就变成“既不能多建也不能少建”更新会死锁maxUnavailable0或正整数/百分比可以设置为0表示更新过程中必须保持所有Pod可用核心思想是这两个不等式期望运行的Pod总数上限 replicas maxSurge 期望可用的Pod总数下限 replicas - maxUnavailable控制器在整个滚动过程中会不断计算当前的总Pod数和可用Pod数确保它们分别不超过上限、不低于下限。手动创建或删除Pod、滚动更新、扩缩容这些动作都必须满足这两个约束。举个具体例子replicas: 3maxSurge: 1maxUnavailable: 0初始状态旧ReplicaSet有3个Pod全部Ready。控制器创建一个新Pod新ReplicaSet此时总Pod数4可用Pod数3。新Pod变为Ready可用Pod数4控制器删掉一个旧Pod此时总Pod数3可用Pod数3。再创建一个新Pod总Pod数回4等它Ready再删一个旧Pod……重复这个循环直到旧Pod清零、新Pod达到3个。这个配置组合的语义是更新过程中永远不让可用Pod数量低于3但允许临时多出1个Pod去做轮换。这意味着只要集群资源够新Pod的启动速度和旧Pod的删除速度协调得好服务几乎不会有任何中断。再举另一个组合replicas: 3maxSurge: 0maxUnavailable: 1这个配置不允许多建Pod但允许更新过程中有1个Pod不可用。执行顺序变成控制器先删掉一个旧Pod此时总Pod数2可用Pod数2。创建一个新Pod总Pod数回3等它Ready。再删一个旧Pod再建一个新Pod……循环到全部替换完成。这个配置的语义是不允许Pod总数超过3节省资源但会有一个Pod的短暂不可用窗口。如果两个参数都设成0呢那既不能多建也不能少删控制器没法在保持3个Pod的情况下替换内容更新会卡住。所以kubectl会直接报错拒绝这个配置strategy.rollingUpdate: maxSurge or maxUnavailable can not be both 0。这两个参数怎么搭取决于你更在意资源占用还是服务稳定性。资源紧张的集群用maxSurge: 0, maxUnavailable: 1比较稳妥对可用性极度敏感的在线业务用maxSurge: 1, maxUnavailable: 0更合适。2.4 用百分比配置时的隐藏规则百分比配置在实际生产里用得非常多但有个隐藏规则很多人不清楚——计算是基于replicas向上取整且最小值是1除非replicas为0。举个例子replicas: 4maxSurge: 10%10%的4等于0.4向上取整后是1。maxUnavailable: 25%25%的4等于1正好是1。再看replicas: 2maxSurge: 10%10%的2等于0.2向上取整后是1。哪怕你想表达“多建0.2个Pod”实际生效也是1个。还有一个我踩过坑的情况replicas: 20maxUnavailable: 5%5%的20等于1但控制器在更新初期可能会直接干掉1个旧Pod如果这1个Pod恰好在承担很高的流量可能会出现短暂的错误率升高。不要以为“5%很少就没影响”对于大规模副本你要关注的是“这个百分比的绝对值到底有多少个Pod”。3. 实操过程与核心环节实现3.1 准备一个可以动手的实验环境纸上谈兵没意思我建议你亲手跑一遍下面的实验。你只需要一个k8s集群单节点也行kind或者minikube都够用。实在没有现成环境的用kind创建一个单节点集群也就两分钟kind create cluster --name deploy-demo创建完确认一下节点状态kubectl get nodes看到Ready状态就可以继续了。下面的实验我特意选用nginx镜像启动快、日志清晰、方便观察更新过程。3.2 实验一观察Recreate的“真空期”先创建一个Recreate策略的Deploymentkubectl create deployment web-recreate --imagenginx:1.25 --replicas3 kubectl set strategy deployment/web-recreate --typeRecreate然后确认一下策略配置kubectl get deployment web-recreate -ojsonpath{.spec.strategy}{\n} # 输出{type:Recreate}再开一个终端用kubectl get pods -w实时观察Pod的变化。现在触发一次更新把镜像从1.25换成1.26kubectl set image deployment/web-recreate nginxnginx:1.26如果你手速够快会看到这样的过程三个web-recreate-xxx的Pod先是进入Terminating状态然后全部消失中间有一段时间kubectl get pods里一个Pod都没有直到新的三个Pod慢慢变成Running和Ready。这一段时间就是服务中断的真空期。为了量化它你可以同时跑一个死循环请求来观察中断时长比如while true; do curl -s -o /dev/null -w %{http_code}\n http://service-ip/; sleep 0.1; done实际测下来nginx启动快中断窗口可能只有几秒但如果你的镜像启动慢或者旧Pod有耗时的优雅退出钩子中断时间会非常明显。这个实验能让你直观理解Recreate的成本。实操心得我每次给业务方讲Recreate的代价都会现场演示这个实验。与其解释半天“会中断服务”不如让他们亲眼看到kubectl get pods -w里那一大段“无Pod”的时间。看得见的中断才叫中断。3.3 实验二观察RollingUpdate的滚动节奏再创建一个RollingUpdate策略的Deployment参数用生产常用的maxSurge: 1, maxUnavailable: 0kubectl create deployment web-rolling --imagenginx:1.25 --replicas3 kubectl set strategy deployment/web-rolling --typeRollingUpdate --rolling-update-max-surge1 --rolling-update-max-unavailable0同样用kubectl get pods -w观察kubectl set image deployment/web-rolling nginxnginx:1.26你会看到旧Pod不会立即被删而是先出现一个新的web-rolling-新hash-xxx的Pod等它变成Running和Ready之后才有一个旧Pod被终止。接下来再创建第二个新Pod、再删第二个旧Pod直到三个Pod全部替换。整个过程中kubectl get pods里永远至少有3个Pod是Ready的——这就是maxUnavailable: 0的效果。如果你想看更明显的“滚动”过程把replicas加到10、maxSurge设成2会看到新旧版本交替持续一段时间期间新老Pod共存这个“共存”正是RollingUpdate的核心特征。我建议你在这个实验中同时观察ReplicaSet的变化kubectl get rs -l appweb-rolling -w能看到新旧两个ReplicaSet并存旧RS的副本数逐渐减少新RS的副本数逐渐增加最终旧RS的desired变成0新RS接管全部副本。很多面试题问“Deployment更新过程中有几个ReplicaSet”这个命令一跑就全明白了。3.4 实验三更新卡住时怎么排查RollingUpdate有个常见问题新Pod一直起不来更新流程卡在那里。为了模拟这个场景我把镜像故意改成一个不存在的tagkubectl set image deployment/web-rolling nginxnginx:9.9.9这时候你会看到kubectl rollout status deployment/web-rolling # 输出Waiting for deployment web-rolling rollout to finish: 1 out of 3 new replicas have been updated... # 然后一直卡在这里用kubectl get pods查看会发现新Pod处于ImagePullBackOff或者ErrImagePull状态。关键点来了因为maxUnavailable: 0旧Pod一个都不会被删整个更新过程就卡住了。这时候系统实际上是安全的旧版本服务还在正常跑只是新版本起不来。排查这个问题按照这个顺序来kubectl describe pod 新Pod名看Events里的具体报错。如果是镜像问题会看到Failed to pull image。kubectl get events --sort-by.lastTimestamp看整个命名空间里最近发生了什么。确认新Pod是否被调度到了合适的节点、是否有资源可用。修复方式很简单把镜像改回正确的tag即可kubectl set image deployment/web-rolling nginxnginx:1.26 kubectl rollout status deployment/web-rolling这个实验告诉我们一个重要的判断逻辑当RollingUpdate卡住时优先怀疑新版本Pod的启动问题而不是控制器配置问题。90%的情况都是镜像拉取失败、探针失败、资源不足这三类原因。3.5 回滚操作的高效姿势更新完了想回滚用kubectl rollout undokubectl rollout undo deployment/web-rollingundo本质上也是触发一次新的滚动更新把Pod模板恢复成上一个版本。你可以指定回滚到某个特定版本kubectl rollout history deployment/web-rolling kubectl rollout undo deployment/web-rolling --to-revision2这里有个容易被忽略的点kubectl rollout history默认只显示REVISION和CHANGE-CAUSE如果创建Deployment时没有加kubectl create --recordtrue新版本k8s默认不再自动recordCHANGE-CAUSE会是none不太方便辨认版本。建议创建Deployment时就养成加--recordtrue的习惯或者直接在YAML的metadata.annotations里写清楚kubernetes.io/change-cause。对于Recreate策略的Deployment回滚同样是把Pod再杀一遍再建一遍中断窗口和普通更新一样不要指望回滚能跳过这个成本。4. 常见问题与排查技巧实录4.1 “Recreate更新后Pod卡在Terminating”怎么处理Recreate更新时如果某个Pod一直处于Terminating状态新Pod就永远起不来。常见原因是Pod里的进程没有响应SIGTERMkubelet默认有terminationGracePeriodSeconds默认30秒的宽限期等满了之后应该强制杀但有时节点上的容器运行时containerd/docker出问题或者节点本身负载太高强制删除也迟迟没有完成。排查思路kubectl describe pod 卡住的Pod看Events里有没有Killing或者FailedKillPod的记录。检查节点状态kubectl get nodes如果节点NotReady那问题在节点上。如果实在等不及可以手动强制删kubectl delete pod Pod名 --force --grace-period0强制删除是最后手段不建议在生产环境常规使用因为可能造成Pod清理不干净、资源泄漏等次生问题。实操心得遇到Recreate卡在Terminating我一般先检查有没有preStop钩子。很多时候是钩子里的命令在等待一个永远不会返回的响应或者钩子脚本自己卡住了。解决思路是给钩子命令加超时机制比如在shell脚本里用sleep配合timeout命令或者缩短terminationGracePeriodSeconds。4.2 maxUnavailable为0时为什么还会出现服务中断这是很多人在maxUnavailable: 0配置下依然遇到服务失败时的疑惑。理论上0表示不允许不可用Pod但实际更新过程中还是会出现短时间错误原因通常有以下几种第一Service的endpoint更新滞后于Pod状态。Pod变成Ready之后kube-proxy和endpoint controller需要几秒钟时间把新Pod的IP同步到Service的后端列表里。如果旧Pod已被删除而新Pod还没被加入endpoint这个窗口期内请求就会失败。k8s官方给出的参考值是--sync-proxy-period默认30秒但kube-proxy通常会更频繁地同步。第二Pod的启动和退出顺序问题。maxUnavailable: 0保证的是“可用Pod数量不低于replicas”但不保证“所有旧Pod一直保持可用”。控制器在某个时刻删除旧Pod之后Service的endpoint还没摘除它这个旧Pod虽然状态还是Running但已经开始处理SIGTERMTCP连接可能被重置正在进行的请求就会中断。第三容器内应用的优雅退出做得不好。即使Pod被正确地从endpoint中移除已建立的TCP连接比如长连接、WebSocket可能还会被路由到即将终止的Pod上。如果应用没有正确处理连接关闭、没有主动向客户端发FIN/RST客户端就会等超时。解决办法有几种给Pod配置preStop钩子在收到SIGTERM前先sleep 5~10秒等endpoint更新完成再退出。这是最常用的补偿手段。使用ReadinessGate配合Pod的Deletion Cost或者接入更复杂的流量治理方案。应用层做重试机制客户端遇到连接失败自动重试到其他Pod。4.3 maxSurge太大导致集群资源被吃光maxSurge允许滚动更新期间多创建Pod但如果设得太大使节点资源可能瞬间不够用。我在生产里见过有人把maxSurge: 50%配给一个replicas: 100的大集群更新一触发节点内存立刻打满调度器疯狂报Insufficient memory连系统Pod都被挤到了驱逐边缘。排查这类问题重点看这几个指标kubectl top nodes kubectl describe node 节点名 | grep -A 10 Allocated resources如果发现节点资源余量很小maxSurge一定要保守。我的建议是资源使用率常年超过70%的集群maxSurge不要超过总数的20%如果是核心在线业务直接用maxSurge: 1 分批发布才是稳妥选择。另外提醒一句RollingUpdate只是在“更新期间”允许超卖如果业务本身的Pod总数再加上maxSurge就会击穿集群容量那说明你的集群容量本来就该扩容了。4.4 更新进度条一直卡着不动kubectl rollout status卡在某个百分比不动除了Pod启动失败外还有一个常见原因新Pod一直处于Pending状态原因是调度不成功。这时候分两步看第一步看Pod为什么Pendingkubectl describe pod 新Pod名Events里常见的几种报错对应关系Events报错原因解决办法0/3 nodes are available所有节点都有taint或资源不足检查节点taint和资源水位Insufficient cpu/memory节点资源不够扩节点或临时调整副本数node.kubernetes.io/not-ready节点不健康先恢复节点failed to fit in any nodePod请求超过节点可分配资源检查requests配置是否过大第二步如果调度没问题但Pod卡在ContainerCreating多半是镜像拉取慢、存储卷挂载失败、CNI网络插件异常。优先看节点上的kubelet日志journalctl -u kubelet -f排查滚动更新卡住的问题核心思路永远是“看Pod的Events、看节点的水位、看控制器的日志”三板斧下来基本能定位90%的问题。最后的几点实操体会从我自己维护的集群经验来说Recreate和RollingUpdate没有绝对的优劣关键是把它们的脾气摸清楚。Recreate适合那些“一次切换、干净利落”的场景但一定要处理好preStop和优雅退出否则中断窗口会被无限拉长RollingUpdate是线上服务的默认选择但参数的组合要结合集群资源和服务特性精细调整不能无脑复制别人的配置。我个人最常用的组合是maxSurge: 1、maxUnavailable: 0加preStop sleep 10这算是一个比较稳妥的起点。如果你刚上手k8s强烈建议在测试集群里把这两个策略各跑一遍把seth image、rollout status、rollout undo这些命令敲熟再配合kubectl get pods -w观察整个过程。纸上得来终觉浅亲手触发一次更新、亲眼看到Pod的变更过程比看十篇文档都有用。