1. 概述
Kubernetes 是一个容器编排平台，极大简化了应用的部署流程。它提供的一项重要机制是记录部署历史并在需要时回滚，这使得应用部署变得更加可控和安全。
在本文中，我们将深入探讨 Kubernetes 中的 Deployment 资源及其滚动更新（Rollout）机制。你将了解 Deployment 是如何管理 Pod 和 ReplicaSet 的，以及如何通过 kubectl 命令管理更新、回滚和暂停/恢复等操作。
2. Kubernetes 中的 Deployment 滚动更新机制
Kubernetes Deployment 是一种声明式资源，用于管理 Pod 和 ReplicaSet。我们通过定义 DeploymentSpec 来描述期望状态，Deployment 控制器会不断协调当前状态与期望状态的一致性。
最基础的 Deployment 配置包括副本数（replicas）和 Pod 模板（template）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: alpine:latest
command: ["sleep", "infinity"]
上面的 YAML 文件定义了一个使用 alpine 镜像的 Deployment，副本数为 3。这意味着 Kubernetes 会始终确保有 3 个 Pod 在运行。
Deployment 的另一个核心功能是控制更新的发布策略（Rollout Strategy）。当我们更新 Deployment（如更换镜像版本）时，Kubernetes 会根据配置的策略来决定如何逐步将新版本应用到所有 Pod 上。
3. 滚动更新策略
我们通过 DeploymentSpec 中的 strategy 字段来指定更新策略。主要有两种方式：
3.1 Recreate 策略
strategy:
type: Recreate
该策略会一次性删除所有旧版本 Pod，然后创建新版本 Pod。适用于无状态服务或可容忍短暂停机的场景。但对生产环境来说，这会导致服务中断，不推荐使用。
3.2 RollingUpdate 策略（默认）
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 0
这是 Deployment 的默认策略，采用渐进式更新的方式，逐步替换旧 Pod，同时保持服务可用。
maxSurge：表示最多可以超出期望副本数的 Pod 数量。例如，设置为 2 表示最多可以同时运行 5 个 Pod（期望是 3 个）。maxUnavailable：表示更新过程中最多允许不可用的 Pod 数量。设为 0 表示不允许任何 Pod 不可用。
📌 踩坑提示：如果你的集群资源紧张，建议适当调高 maxUnavailable 并将 maxSurge 设为 0，避免资源不足导致调度失败。
4. 使用 kubectl 管理 Deployment 滚动更新
kubectl rollout 是管理 Deployment 更新的核心命令。我们可以通过它查看历史、回滚、暂停/恢复更新等。
4.1 查看 Deployment 更新历史
kubectl rollout history deployment/myapp-deployment
输出示例：
deployment.apps/myapp-deployment
REVISION CHANGE-CAUSE
1 <none>
2 update image version from 3.16 to 3.17
REVISION：表示当前的更新版本号。CHANGE-CAUSE：显示更新原因，可通过注解设置。
📌 技巧：更新前建议添加注解以记录变更内容：
kubectl annotate deployment/myapp-deployment kubernetes.io/change-cause="update image version from 3.16 to 3.17"
4.2 回滚 Deployment
如果发现新版本有问题，可以使用以下命令回滚：
kubectl rollout undo deployment/myapp-deployment
默认回滚到上一版本。也可以指定版本号：
kubectl rollout undo --to-revision=2 deployment/myapp-deployment
4.3 暂停和恢复 Deployment 更新
在某些场景下，我们希望更新配置但不立即生效，可以使用暂停功能：
kubectl rollout pause deployment/myapp-deployment
此时即使你修改了 Deployment 的配置（如更新镜像），也不会触发滚动更新。
查看当前状态：
kubectl rollout status deployment/myapp-deployment
输出示例：
Waiting for deployment "myapp-deployment" rollout to finish: 0 out of 3 new replicas have been updated...
当准备就绪后，恢复滚动更新：
kubectl rollout resume deployment/myapp-deployment
再次查看状态：
kubectl rollout status deployment/myapp-deployment
输出示例：
deployment "myapp-deployment" successfully rolled out
✅ 优点总结：
- 暂停/恢复机制非常适合在 CI/CD 流水线中使用。
- 可以在更新前做预检，确认无误后再恢复。
5. 总结
Deployment 是 Kubernetes 中用于管理 Pod 生命周期的核心资源之一。它不仅提供了声明式配置的能力，还支持灵活的滚动更新策略，确保服务在更新过程中持续可用。
我们介绍了以下关键点：
| 功能 | 命令 | 说明 |
|---|---|---|
| 查看更新历史 | kubectl rollout history |
显示所有版本 |
| 回滚更新 | kubectl rollout undo |
回滚至上一或指定版本 |
| 暂停更新 | kubectl rollout pause |
停止自动更新 |
| 恢复更新 | kubectl rollout resume |
继续执行更新 |
| 查看状态 | kubectl rollout status |
检查更新进度 |
📌 建议：
- 生产环境优先使用
RollingUpdate策略。 - 配置合理的
maxSurge和maxUnavailable值。 - 每次更新都应添加注解，方便后续排查问题。
通过熟练掌握 Deployment 的滚动更新机制和相关命令，你可以更高效地管理 Kubernetes 集群中的应用发布与回滚流程。