K8s滚动更新原理与实战解析

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《K8s滚动更新机制详解》，聊聊，希望可以帮助到正在努力赚钱的你。

滚动更新由Deployment控制器触发，依赖strategy.type设为"RollingUpdate"及rollingUpdate.maxSurge、maxUnavailable配置；其本质是逐批扩缩Pod，而非Kubernetes直接滚动。

滚动更新是怎么触发的？靠 Deployment 的 strategy.type 和 rollingUpdate 配置

Kubernetes 本身不直接“滚动”，真正执行滚动更新的是 Deployment 控制器。它通过声明式配置决定如何替换旧 Pod：只要把 strategy.type 设为 "RollingUpdate"（默认值），再配好 rollingUpdate.maxSurge 和 rollingUpdate.maxUnavailable，控制器就会按策略逐批扩缩。

常见误配点：

• maxSurge: 1 表示最多允许比期望副本数多启动 1 个新 Pod；设成 "25%" 则按百分比向上取整（比如 replicas=4 时，允许最多多启 1 个）
• maxUnavailable: 0 意味着更新期间不允许任何服务中断——必须先扩出新 Pod 并就绪，才能删旧 Pod；但若新 Pod 卡在 ContainerCreating 或健康检查失败，滚动会卡住
• 没写 rollingUpdate 块？K8s 会用默认值：maxSurge=25%, maxUnavailable=25%，这在小规模集群（如 replicas=1）下可能直接导致服务不可用

kubectl set image 和 kubectl apply -f 更新行为一样吗？

本质一样，都是修改 Deployment 的 spec.template.spec.containers[*].image 字段，触发控制器重建 Pod。但操作路径不同，影响也不同：

• kubectl set image deploy/myapp mycontainer=nginx:1.25 是命令式修改，适合快速迭代；但它绕过本地 YAML 文件，容易和 GitOps 流程脱节
• kubectl apply -f deploy.yaml 是声明式更新，推荐用于生产；注意：如果 YAML 中没显式写 strategy，apply 后会继承默认策略，而非保留上次手动设置的值
• 两者都会导致 deployment.kubernetes.io/revision 注解递增，且旧 ReplicaSet 不会被立即删除（默认保留 revisionHistoryLimit: 10 个）

滚动过程中 Pod 为什么卡在 Terminating 状态？

这不是滚动机制的问题，而是容器自身生命周期没处理好。K8s 发送 SIGTERM 后，会等待 terminationGracePeriodSeconds（默认 30 秒）再发 SIGKILL。如果应用没响应 SIGTERM、或清理逻辑阻塞（比如数据库连接未关闭、文件句柄未释放），Pod 就会 hang 在 Terminating。

• 检查容器是否捕获并处理 SIGTERM：Node.js 应用需监听 process.on("SIGTERM", ...)；Java 应用建议用 spring-boot-starter-actuator + livenessProbe 配合优雅停机
• 确认 terminationGracePeriodSeconds 是否足够：高负载场景下可设为 60 或 120
• 避免在 preStop hook 中执行长耗时命令（如 sleep 30），它会进一步延长 Terminating 时间

滚动更新失败后怎么回滚？kubectl rollout undo 能恢复到哪一版？

kubectl rollout undo deployment/myapp 默认回滚到上一个 ReplicaSet（即 revision-1），前提是那个 ReplicaSet 还存在（受 revisionHistoryLimit 限制）。它本质是把当前 Deployment 的 spec.template 替换为历史版本的模板，并触发新一轮滚动。

• 想回滚到特定版本？加 --to-revision=3；用 kubectl rollout history deploy/myapp 查看可用 revision 列表
• 回滚不是“撤销命令”，而是另一次滚动更新——所以同样受 maxUnavailable 等策略约束，也可能失败
• 如果已手动删过旧 ReplicaSet，或 revisionHistoryLimit 太小（比如设为 1），就只能靠重新 apply 旧版 YAML 来恢复

真正难的不是触发滚动，而是让每个 Pod 在新旧交替时既不丢请求，也不卡退出——这取决于镜像里程序怎么写，而不是 K8s 配置怎么写。

以上就是《K8s滚动更新原理与实战解析》的详细内容，更多关于的资料请关注golang学习网公众号！