Kubernetes滚动更新通过Deployment+ReplicaSet分层实现零中断服务替换，先创建新ReplicaSet并按maxSurge/maxUnavailable策略增新减旧，依赖readinessProbe和preStop hook保障平滑过渡，支持基于历史版本快速回滚。

Kubernetes 通过 Deployment 控制器 + ReplicaSet 分层机制实现滚动更新，核心是**不中断服务的前提下逐步替换旧 Pod**。 整个过程不是直接修改现有 Pod，而是由控制器自动协调新旧资源的增减，依赖声明式配置和持续的状态调和循环。

滚动更新的执行流程

当你修改 Deployment 的 Pod 模板（如镜像版本、环境变量等），触发更新后，系统会：

• 创建一个新的 ReplicaSet（对应新版本 Pod 模板）
• 按策略控制新 ReplicaSet 的副本数逐步增加，同时减少旧 ReplicaSet 的副本数
• 新 Pod 启动并通过 readinessProbe 后，才被 Service 加入 endpoint 列表
• 旧 Pod 在确认新 Pod 就绪后，才被优雅终止（支持 preStop hook 延迟销毁）
• 新旧 ReplicaSet 短暂共存，直到旧 ReplicaSet 副本数降为 0

关键参数控制更新行为

滚动节奏由 maxSurge 和 maxUnavailable 共同决定：

• maxSurge：更新期间允许超出期望副本数的 Pod 数量（可设为绝对值或百分比）
• maxUnavailable：更新期间最多不可用的 Pod 数量（同样支持绝对值或百分比）

例如：replicas: 6，设置 maxSurge: 1、maxUnavailable: 0，表示每次最多新增 1 个新 Pod，且全程不允许任何 Pod 不可用——即先扩再缩，零中断。

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

保障平滑过渡的两个必要实践

仅靠参数还不够，真实生产中需配合以下机制避免请求失败：

• 就绪探针（readinessProbe）：确保 Pod 真正可服务后才接入流量，防止请求打到启动中或未初始化完成的容器
• 预停止钩子（preStop hook）：在 Pod 终止前执行 sleep 或优雅关闭逻辑，留出时间让 endpoint 和 kube-proxy 完成路由清理

版本历史与回滚基础

每次滚动更新都会生成新的 ReplicaSet，并保留历史记录（受 revisionHistoryLimit 控制）。只要没被清理，就能通过 kubectl rollout undo 快速回退到任意历史版本——这依赖于 Deployment 对多个 ReplicaSet 的统一编排能力。