Deployment 与 ReplicaSet 是什么，rolling update 和回滚如何工作？

Question

IT Interview Practice · Accepted Answer

**Deployment** 是运行无状态（stateless）应用的标准 controller。它管理 **ReplicaSet**，而一个 ReplicaSet 保持指定数量的相同 Pod 运行。你编辑 Deployment；它为你编排 **rolling update** 和**回滚（rollback）**。

## 层级结构

```text
Deployment  → 声明期望状态 + 更新策略（你管理的东西）
   └── ReplicaSet  → 确保存在 N 个相同的 Pod（每个应用版本一个）
          └── Pod  → Pod → Pod ...  （实际运行的副本）

每出一个新版本，Deployment 就创建一个新的 ReplicaSet 并把 Pod 逐步迁移过去。
```

## 一个 Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # 更新期间最多 1 个 Pod 不可用
      maxSurge: 1            # 最多比期望数量多 1 个 Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update：零停机版本切换

```bash
kubectl set image deployment/web web=myapp:2.0   # 触发一次 rolling update
kubectl rollout status deployment/web            # 观察进度
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (开始：4 个旧 Pod)
      █████       启动 1 个新 Pod (v2)，现在共 5 个 (surge)
      ███ █       旧的减到 3 个，新的已 Ready
      ...逐步迁移...
  v2: ████        (结束：4 个新 Pod，旧 ReplicaSet 缩到 0)
流量只会到达通过其 readiness probe 的 Pod → 不停机。
```

## 发布出问题时回滚

```bash
kubectl rollout history deployment/web       # 列出各个 revision
kubectl rollout undo deployment/web          # 回滚到上一个 revision
kubectl rollout undo deployment/web --to-revision=3
```

因为旧的 ReplicaSet 被保留（缩到 0），回滚很快：Kubernetes 只需把之前的 ReplicaSet 再扩回来、把新的缩下去。

## 扩缩（Scaling）

```bash
kubectl scale deployment/web --replicas=10   # 改变期望数量
```

## 为什么这很重要

Deployment 是在 Kubernetes 上运行无状态应用的主力，因此理解它以及它与 ReplicaSet 的关系是必备的日常知识。分层是关键洞见：你管理一个 **Deployment**，它拥有若干 **ReplicaSet**（每个版本一个），而每个 ReplicaSet 保证一定数量的相同 Pod 在运行——一连串调和循环共同带来自愈和稳定的副本数。真正的威力在于 Deployment 如何处理变更：一次 **rolling update** 会创建一个新的 ReplicaSet 并将 Pod 从旧到新逐步迁移，受 `maxSurge` 和 `maxUnavailable` 控制，从而保持容量——再结合决定哪些 Pod 接收流量的 readiness probe——发布得以**零停机**完成。因为之前的 ReplicaSet 被保留（缩到零而非删除），**回滚**既快又安全：`kubectl rollout undo` 只是把旧版本重新扩上来、把出问题的缩下去，这正是发布出错时你会用到的。理解这些机制——外加如何扩缩（`kubectl scale`）和查看进度（`kubectl rollout status/history`）——是在 Kubernetes 上安全交付软件的基础，也体现了定义该平台在生产中运作方式的声明式、controller 驱动的模型。

层级结构

一个 Deployment manifest

Rolling update：零停机版本切换

发布出问题时回滚

扩缩（Scaling）

为什么这很重要

相关问题