Deployment 与 ReplicaSet：副本管理与滚动更新

1. Deployment、ReplicaSet 与 Pod 的职责#

1. 什么是 Deployment？#

Deployment 是 Kubernetes 中用于管理无状态应用的工作负载控制器。

它并不直接创建和管理容器，而是通过 ReplicaSet 间接管理 Pod。

架构关系：

flowchart TB
    N0["Deployment"]
    N1["ReplicaSet-v1"]
    N2["ReplicaSet-v2"]
    N3["Pod"]
    N4["Pod"]
    N5["Pod"]
    N6["Pod"]
    N7["Pod"]
    N8["Pod"]
    N0 --> N1
    N0 --> N2
    N1 --> N3
    N1 --> N4
    N1 --> N5
    N2 --> N6
    N2 --> N7
    N2 --> N8

Deployment 负责：

1. 创建 ReplicaSet。
2. 管理 ReplicaSet 的版本。
3. 控制 Pod 副本数量。
4. 实现滚动更新。
5. 实现版本回滚。
6. 管理应用发布历史。

ReplicaSet 负责：

1. 维护 Pod 副本数量。
2. 发现异常 Pod。
3. 创建新的 Pod 补充副本。

Pod 负责：

1. 运行容器。
2. 提供应用服务。

2. 为什么需要 Deployment？#

对比一下：

实际生产环境中：

无状态应用通常优先使用 Deployment，而不是直接使用 ReplicaSet。

2. ReplicaSet 是什么？#

1. 基本概念#

ReplicaSet 是 Kubernetes 中用于维护 Pod 副本数量的控制器。

它的核心任务是：

确保指定数量的 Pod 副本始终处于符合要求的状态。

例如，我们希望运行 3 个 Nginx Pod：

1
replicas: 3

ReplicaSet 会持续检查实际 Pod 数量。

假设：

1
期望副本数：3
2

3
实际情况：
4

5
Pod-1   Running
6
Pod-2   Running
7
Pod-3   Running

此时状态正常。

如果 Pod-2 意外退出：

1
期望副本数：3
2

3
实际情况：
4

5
Pod-1   Running
6
Pod-2   Terminated
7
Pod-3   Running

ReplicaSet 发现实际副本数不足，就会创建新的 Pod。

1
Pod-1   Running
2
Pod-2   Terminated
3
Pod-3   Running
4
Pod-4   Running（新创建）

最终恢复到 3 个符合要求的副本。

注意：ReplicaSet 不是直接重启原来的 Pod，而是创建新的 Pod 来满足副本数量。

2. ReplicaSet 的工作原理#

ReplicaSet 的核心是控制循环（Reconciliation Loop）。

工作过程：

flowchart TB
    N0["ReplicaSet Controller"]
    N1["获取期望副本数"]
    N2["获取实际 Pod 数量"]
    N3["比较两个数量"]
    N4["创建 Pod"]
    N5["删除 Pod"]
    N6["再次检查状态"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 -->|"数量不足"| N4
    N3 -->|"数量过多"| N5
    N4 --> N6
    N5 --> N6

这就是 Kubernetes 的声明式控制机制。

你只需要声明：

1
replicas: 3

不需要自己编写程序不断检查 Pod 数量。

ReplicaSet Controller 会自动完成协调。

3. Label 与 Selector：标签查询与匹配规则#

这是理解 ReplicaSet 的关键，也是 CKA 常见考点。

1. 什么是 Label？#

Label（标签）是 Kubernetes 中附加在资源对象上的键值对。

例如：

1
metadata:
2
  labels:
3
    app: nginx
4
    env: production
5
    version: v1

一个资源可以有多个标签。

标签本身只是元数据，不会自动产生管理行为。

真正利用标签进行资源筛选的是 Selector。

2. Label 查询命令#

查看所有 Pod 的标签：

1
kubectl get pods --show-labels

输出：

1
NAME       LABELS
2
nginx-1    app=nginx,env=prod
3
nginx-2    app=nginx,env=test
4
nginx-3    app=redis,env=prod

根据标签查询：

1
kubectl get pods -l app=nginx

查询多个标签：

1
kubectl get pods -l app=nginx,env=prod

查询不包含某个标签：

1
kubectl get pods -l 'env!=test'

3. Selector 的两种表达方式#

Kubernetes 主要支持两类标签选择表达式：

1. 第一种：matchLabels#

1
selector:
2
  matchLabels:
3
    app: nginx
4
    env: production

含义：

1
app = nginx
2
AND
3
env = production

两个条件必须同时满足。

2. 第二种：matchExpressions#

1
selector:
2
  matchExpressions:
3
    - key: app
4
      operator: In
5
      values:
6
        - nginx
7
        - apache

表示：

1
app = nginx
2
OR
3
app = apache

常见操作符：

例如：

1
selector:
2
  matchExpressions:
3
    - key: env
4
      operator: In
5
      values:
6
        - prod
7
        - test
8

9
    - key: app
10
      operator: Exists

表示：

1
env 属于 prod 或 test
2
AND
3
存在 app 标签

注意：同一个 Selector 中的多个条件通常是 AND 关系；In 中的多个 values 才是 OR 关系。

4. ReplicaSet 如何识别和管理 Pod？#

这是一个非常重要的底层原理。

假设我们创建了一个 ReplicaSet：

1
spec:
2
  replicas: 3
3
  selector:
4
    matchLabels:
5
      app: nginx

那么 ReplicaSet 会根据标签选择符合条件的 Pod。

例如，集群中存在：

1
Pod-A：app=nginx
2
Pod-B：app=nginx
3
Pod-C：app=redis
4
Pod-D：app=nginx

ReplicaSet 只会把符合选择器的 Pod 纳入管理。

但这里有一个重要问题：

如果某个 Pod 不是 ReplicaSet 创建的，只是恰好具有相同标签，会怎样？

答案：它也可能被 ReplicaSet 认领。

ReplicaSet 并不只管理自己创建的 Pod，还可以通过 Selector 发现符合条件且未被其他控制器认领的 Pod。

不过要注意：

• 已经被其他控制器管理的 Pod，不能被另一个 ReplicaSet 随意抢占。
• 被 ReplicaSet 认领后，会通过 OwnerReference 建立所属关系。
• 直接删除被管理的 Pod，ReplicaSet 仍会补充副本。

1. OwnerReference#

Kubernetes 通过 OwnerReference 建立资源之间的所属关系。

例如：

flowchart TB
    N0["ReplicaSet"]
    N1["Pod"]
    N0 -->|"OwnerReference"| N1

查看 Pod 的 OwnerReference：

1
kubectl get pod <pod-name> \
2
  -o jsonpath='{.metadata.ownerReferences}'

输出中可以看到类似：

1
[
2
  {
3
    "apiVersion": "apps/v1",
4
    "kind": "ReplicaSet",
5
    "name": "nginx-rs"
6
  }
7
]

这表示 Pod 属于 nginx-rs。

OwnerReference 是 Kubernetes 管理资源生命周期和垃圾回收机制的重要基础。

5. ReplicaSet 的 YAML 结构#

下面创建一个完整的 ReplicaSet。

1. 创建 ReplicaSet#

新建文件：

1
vim replicaset.yaml

编写：

1
apiVersion: apps/v1
2
kind: ReplicaSet
3

4
metadata:
5
  name: nginx-rs
6

7
spec:
8
  replicas: 3
9

10
  selector:
11
    matchLabels:
12
      app: nginx
13

14
  template:
15
    metadata:
16
      labels:
17
        app: nginx
18

19
    spec:
20
      containers:
21
        - name: nginx
22
          image: nginx:1.27
23
          ports:
24
            - containerPort: 80

这里有几个关键字段。

其中最重要的是：

• replicas
• selector
• template

2. 理解 selector 和 template#

这是 ReplicaSet 最容易出错的地方。

先看：

1
selector:
2
  matchLabels:
3
    app: nginx

它表示 ReplicaSet 通过标签选择器寻找具有 app=nginx 标签的 Pod。

再看：

1
template:
2
  metadata:
3
    labels:
4
      app: nginx

它表示 ReplicaSet 创建的 Pod 会自动携带 app=nginx 标签。

两者必须匹配。

标签匹配关系

flowchart TB
    N0["ReplicaSet Selector<br/>app=nginx"]
    N1["Pod Template<br/>labels: app=nginx<br/>匹配成功"]
    N2["Pod-1<br/>app=nginx"]
    N3["Pod-2<br/>app=nginx"]
    N4["Pod-3<br/>app=nginx"]
    N0 --> N1
    N1 --> N2
    N1 --> N3
    N1 --> N4

如果标签不匹配，ReplicaSet 就无法正确管理自己创建的 Pod。

6. Deployment YAML 结构#

1. 创建一个 Deployment#

创建文件：

1
vim deployment.yaml

编写：

1
apiVersion: apps/v1
2
kind: Deployment
3

4
metadata:
5
  name: nginx-deployment
6

7
spec:
8
  replicas: 3
9

10
  selector:
11
    matchLabels:
12
      app: nginx
13

14
  template:
15
    metadata:
16
      labels:
17
        app: nginx
18

19
    spec:
20
      containers:
21
        - name: nginx
22
          image: nginx:1.27
23
          ports:
24
            - containerPort: 80

创建：

1
kubectl apply -f deployment.yaml

查看：

1
kubectl get deployments
2
kubectl get replicasets
3
kubectl get pods

你会看到：

1
NAME               READY   UP-TO-DATE   AVAILABLE
2
nginx-deployment   3/3     3            3

同时会创建一个 ReplicaSet：

1
NAME                          DESIRED   CURRENT   READY
2
nginx-deployment-xxxxxxxxxx   3         3         3

以及三个 Pod。

2. Deployment 核心字段#

其中最重要的是 replicas、selector、template 和 strategy。

3. 查看 Deployment 的完整配置#

1
kubectl get deployment nginx-deployment -o yaml

查看运行状态：

1
kubectl describe deployment nginx-deployment

查看 Deployment 管理的 ReplicaSet：

1
kubectl get rs

7. Deployment 扩缩容（Scaling）#

假设现在有一个运行 3 个 Pod 的 Deployment。

需要扩容到 5 个。

1. 使用 scale 命令#

1
kubectl scale deployment nginx-deployment --replicas=5

查看：

1
kubectl get deployment
2
kubectl get pods

缩容到 2 个：

1
kubectl scale deployment nginx-deployment --replicas=2

2. 使用 YAML 修改#

1
spec:
2
  replicas: 5

执行：

1
kubectl apply -f deployment.yaml

3. 使用 edit 修改#

1
kubectl edit deployment nginx-deployment

修改：

1
spec:
2
  replicas: 5

保存退出即可。

4. 扩缩容的底层过程#

flowchart TB
    N0["kubectl scale"]
    N1["Deployment.spec.replicas"]
    N2["Deployment Controller"]
    N3["ReplicaSet.spec.replicas"]
    N4["ReplicaSet Controller"]
    N5["创建或删除 Pod"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5

注意：扩容和缩容一般不会触发新的 Deployment 版本发布，因为它们不改变 Pod 模板。

8. Deployment 更新策略（Deployment Strategy）#

这是本节最重要的知识点，也是 CKA 高频考点。

Kubernetes Deployment 支持两种更新策略：

1. RollingUpdate：滚动更新。
2. Recreate：重新创建。

1. RollingUpdate（滚动更新）#

滚动更新是 Deployment 默认使用的更新策略。

核心思想：

逐步创建新版本 Pod，同时逐步删除旧版本 Pod，尽可能保证应用持续可用。

假设：

• 当前有 4 个 Nginx 1.27 Pod。
• 需要升级到 Nginx 1.28。
• 副本数量为 4。

初始状态：

初始版本：nginx:1.27

Pod-1 v1.27

Pod-2 v1.27

Pod-3 v1.27

Pod-4 v1.27

4 个旧版本 Pod 正常运行

开始滚动更新：

阶段一：创建新版本 Pod

旧版

旧版

旧版

新版

3 个旧版 + 1 个新版

阶段二：逐步替换旧版本

旧版

旧版

新版

新版

2 个旧版 + 2 个新版

阶段三：完成升级

Pod-1 v1.28

Pod-2 v1.28

Pod-3 v1.28

Pod-4 v1.28

升级完成

实际替换过程由控制器根据更新参数、Pod 就绪状态和调度情况动态协调，并不一定严格按照上述每一步的数量执行。

1. RollingUpdate YAML#

1
spec:
2
  replicas: 4
3

4
  strategy:
5
    type: RollingUpdate
6

7
    rollingUpdate:
8
      maxSurge: 1
9
      maxUnavailable: 1

这里有两个非常重要的参数。

2. maxSurge（最大超出数量）#

表示滚动更新过程中，允许超过期望副本数的最大 Pod 数量。

例如：

1
replicas: 4
2

3
maxSurge: 1

含义：

1
期望副本数：4
2
最大额外副本：1
3

4
更新期间最多允许：
5
4 + 1 = 5 个 Pod

也就是说，更新过程中最多可以同时存在 5 个目标 Deployment 管理的旧、新版本 Pod。

3. maxUnavailable（最大不可用数量）#

表示滚动更新期间，允许低于期望副本数的最大不可用 Pod 数量。

例如：

1
replicas: 4
2

3
maxUnavailable: 1

含义：

1
期望副本数：4
2

3
最大不可用数量：1
4

5
至少保持：
6
4 - 1 = 3 个可用副本

注意，这里的 Available 是 Deployment 对 Pod 可用性的判断，不完全等同于容器进程处于 Running。

4. 两个参数如何配合？#

假设：

1
replicas: 4
2

3
rollingUpdate:
4
  maxSurge: 1
5
  maxUnavailable: 1

则：

• 最多允许 5 个 Pod。
• 正常更新过程中至少保持 3 个 Available Pod。

比较一下：

两者可以根据业务需求调整。

例如：

方案 A：尽可能保证可用性

1
maxSurge: 1
2
maxUnavailable: 0

先创建新 Pod，等新 Pod 可用后，再逐步删除旧 Pod。

方案 B：尽可能减少资源占用

1
maxSurge: 0
2
maxUnavailable: 1

不允许超过期望副本数，但允许暂时少一个可用副本。

重要规则：

• 两者可以使用整数。
• 也可以使用百分比，例如 25%。
• 默认 maxSurge 为 25%。
• 默认 maxUnavailable 为 25%。
• 两者不能同时为 0。

当使用百分比时：

• maxSurge 向上取整。
• maxUnavailable 向下取整。

例如，副本数为 5：

1
maxSurge: 25%
2
maxUnavailable: 25%

计算：

• maxSurge：5 × 25% = 1.25，向上取整为 2。
• maxUnavailable：5 × 25% = 1.25，向下取整为 1。

因此最多允许 7 个 Pod，至少保持 4 个 Available Pod。

5. Recreate（重新创建）#

另一种更新策略是 Recreate。

它的核心思想：

先删除旧版本的 Pod，再创建新版本的 Pod。

例如：

flowchart TB
    N0["初始状态：<br/>nginx-v1<br/>nginx-v1<br/>nginx-v1"]
    N1["删除所有旧版本 Pod"]
    N2["创建新版本 Pod"]
    N3["nginx-v2<br/>nginx-v2<br/>nginx-v2"]
    N0 --> N1
    N1 --> N2
    N2 --> N3

YAML：

1
spec:
2
  replicas: 3
3

4
  strategy:
5
    type: Recreate

特点：

• 不采用滚动替换。
• 旧版本 Pod 全部删除后，再创建新版本 Pod。
• 更新期间可能出现服务中断。
• 适用于不能同时运行新旧版本的应用。

例如：

某些应用升级时，新旧版本不能同时访问同一份数据或不能同时运行，这时可以考虑 Recreate。

6. 两种更新策略对比#

CKA 必考重点

记忆：

• RollingUpdate：滚动更新。
• Recreate：全部删除后重新创建。

9. Deployment 版本回滚（Rollback）#

这是 Deployment 非常重要的功能。

假设：

1
v1：nginx:1.27
2
v2：nginx:1.28
3
v3：nginx:1.29

现在升级到 v3 后发现应用异常。

需要回到 v2。

Kubernetes 可以通过 Deployment 的历史版本机制进行回滚。

1. 查看更新历史#

1
kubectl rollout history deployment nginx-deployment

输出示例：

1
REVISION  CHANGE-CAUSE
2
1         <none>
3
2         <none>
4
3         <none>

每次 Pod 模板发生新的版本变更，通常会形成一个新的 Revision。

2. 查看某个版本详情#

1
kubectl rollout history deployment nginx-deployment --revision=2

可以查看该版本的 Pod 模板信息。

3. 回滚到上一个版本#

1
kubectl rollout undo deployment nginx-deployment

查看：

1
kubectl rollout status deployment nginx-deployment

4. 回滚到指定版本#

1
kubectl rollout undo deployment nginx-deployment \
2
  --to-revision=2

这样就可以回到 Revision 2。

5. 回滚的底层原理#

Deployment 并不是简单地把旧 Pod 重新启动。

它主要通过调整旧 ReplicaSet 和新 ReplicaSet 的副本数，重新恢复目标版本。

例如：

flowchart TB
    subgraph G0["回滚之前"]
        direction TB
        N0["Deployment"]
        N1["RS-v1<br/>0 Pods"]
        N2["RS-v2<br/>3 Pods"]
    end
    subgraph G1["回滚之后"]
        direction TB
        N3["Deployment"]
        N4["RS-v1<br/>3 Pods"]
        N5["RS-v2<br/>0 Pods"]
    end
    N0 --> N1
    N0 --> N2
    N3 --> N4
    N3 --> N5
    G0 -->|"rollout undo"| G1

因此，ReplicaSet 的历史记录非常重要。

10. Deployment Revision（版本历史管理）#

前面我们已经使用了：

1
kubectl rollout history deployment nginx-deployment

这里进一步理解 Revision。

1. 什么是 Revision？#

Revision 是 Deployment 的发布版本记录。

当 Deployment 的 Pod 模板发生变化时，Deployment Controller 通常会创建新的 ReplicaSet，并形成新的 Revision。

例如：

注意：仅仅修改副本数量，一般不会创建新的 Revision。

因为副本数量不属于 Pod 模板内容。

2. 设置版本变更原因#

可以在 Deployment 中添加：

1
metadata:
2
  annotations:
3
    kubernetes.io/change-cause: "upgrade nginx to 1.28"

这样查看历史记录时，就能看到版本变更原因。

也可以使用：

1
kubectl annotate deployment nginx-deployment \
2
  kubernetes.io/change-cause="upgrade nginx to 1.28"

注意：Annotation 是元数据。单独修改 Annotation 不会因为 Pod 模板变化而触发新的 ReplicaSet Revision。

3. 控制历史版本保留数量#

Deployment 默认保留一定数量的旧 ReplicaSet 历史记录，默认值为 10。

可以修改：

1
spec:
2
  revisionHistoryLimit: 5

表示最多保留 5 个旧版本 ReplicaSet 历史记录。

为什么需要限制？

因为每次更新都可能产生新的 ReplicaSet，如果无限保留，会增加集群中的历史资源数量。

注意：revisionHistoryLimit: 0 表示不保留旧版本历史 ReplicaSet，可能导致无法通过常规 Deployment 回滚到之前的版本。

11. Deployment 暂停与恢复更新#

生产环境中，有时我们需要连续修改多个配置，但不希望每修改一次就触发一次发布。

这时可以使用暂停更新功能。

1. 暂停 Deployment#

1
kubectl rollout pause deployment nginx-deployment

2. 修改镜像#

1
kubectl set image deployment/nginx-deployment \
2
  nginx=nginx:1.29

3. 修改资源限制#

1
kubectl set resources deployment nginx-deployment \
2
  -c nginx \
3
  --limits=cpu=500m,memory=512Mi

4. 恢复更新#

1
kubectl rollout resume deployment nginx-deployment

查看：

1
kubectl rollout status deployment nginx-deployment

整个过程：

flowchart TB
    N0["Deployment"]
    N1["暂停更新"]
    N2["修改镜像"]
    N3["修改资源限制"]
    N4["恢复更新"]
    N5["统一执行更新"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5

注意：

暂停期间对 Pod 模板的修改不会立即启动新的滚动更新，恢复后才会继续协调。

12. Deployment 部署进度与超时控制#

在生产环境中，还有一个问题：

如果新版本一直无法启动，Deployment 会怎样？

例如：

• 镜像无法拉取。
• Pod 一直无法调度。
• Readiness Probe 一直失败。
• 应用启动异常。

Deployment 提供了部署进度超时控制。

1. progressDeadlineSeconds#

示例：

1
spec:
2
  progressDeadlineSeconds: 600

表示：

如果 Deployment 在 600 秒内没有取得新的部署进展，就会被判定为 ProgressDeadlineExceeded。

可以查看：

1
kubectl describe deployment nginx-deployment

可能看到：

1
Conditions:
2
  Type: Progressing
3
  Status: False
4
  Reason: ProgressDeadlineExceeded

注意：

部署超时不意味着 Kubernetes 会自动回滚。

它主要是报告部署进度异常，之后仍可由控制器继续协调，也可以由运维人员主动回滚。

2. minReadySeconds#

示例：

1
spec:
2
  minReadySeconds: 10

含义：

Pod 变为 Ready 后，需要持续保持 Ready 至少 10 秒，才会被 Deployment 认为是 Available。

为什么需要这个配置？

假设应用刚启动时：

flowchart TB
    N0["Pod 启动"]
    N1["Ready"]
    N2["运行 2 秒"]
    N3["立即崩溃"]
    N0 --> N1
    N1 --> N2
    N2 --> N3

如果没有稳定时间要求，Deployment 可能过早地认为新版本已经可用。

设置 minReadySeconds 可以让控制器等待一段稳定时间。

注意：它不会替代 Readiness Probe，也不会自动保证业务完全正常。

13. Deployment 与 Service 的关系#

到目前为止，我们已经学习了：

• Deployment：管理应用副本。
• ReplicaSet：维持 Pod 数量。
• Pod：运行应用。

那么用户如何访问这些 Pod？

通常需要 Service。

架构：

flowchart TB
    N0["Client"]
    N1["Service"]
    N2["Pod-1"]
    N3["Pod-2"]
    N4["Pod-3"]
    N5["Deployment"]
    N6["ReplicaSet"]
    N0 --> N1
    N1 -->|"请求"| N2
    N1 -->|"请求"| N3
    N1 -->|"请求"| N4
    N5 -.->|"管理"| N6
    N6 -.->|"管理"| N2
    N6 -.->|"管理"| N3
    N6 -.->|"管理"| N4

注意：Service 不直接管理 Deployment。

Service 主要通过 Label Selector 选择符合条件的 Pod，并提供稳定的访问入口。

例如：

Deployment 中的 Pod：

1
labels:
2
  app: nginx

Service：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-service
5
spec:
6
  selector:
7
    app: nginx
8
  ports:
9
    - port: 80
10
      targetPort: 80
11
  type: ClusterIP

只要 Pod 的标签匹配，Service 就可以将流量转发给相应的就绪后端。

这也说明为什么标签设计非常重要：

• Deployment 使用 Selector 管理 Pod。
• Service 使用 Selector 选择流量后端。

二者可以使用相同的标签，但职责不同。

14. Deployment 配置示例#

1
apiVersion: apps/v1
2
kind: Deployment
3

4
metadata:
5
  name: web-app
6
  annotations:
7
    kubernetes.io/change-cause: "initial deployment"
8

9
spec:
10
  replicas: 3
11

12
  revisionHistoryLimit: 5
13

14
  minReadySeconds: 10
15

16
  progressDeadlineSeconds: 600
17

18
  selector:
19
    matchLabels:
20
      app: web
21

22
  strategy:
23
    type: RollingUpdate
24

25
    rollingUpdate:
26
      maxSurge: 1
27
      maxUnavailable: 0
28

29
  template:
30
    metadata:
31
      labels:
32
        app: web
33

34
    spec:
35
      containers:
36
        - name: nginx
37
          image: nginx:1.27
38

39
          ports:
40
            - containerPort: 80
41

42
          resources:
43
            requests:
44
              cpu: 100m
45
              memory: 128Mi
46

47
            limits:
48
              cpu: 500m
49
              memory: 256Mi
50

51
          readinessProbe:
52
            httpGet:
53
              path: /
54
              port: 80
55
            periodSeconds: 5
56

57
          livenessProbe:
58
            httpGet:
59
              path: /
60
              port: 80
61
            periodSeconds: 10

15. ReplicaSet 常见故障排查#

1. ReplicaSet 无法创建 Pod#

检查：

1
kubectl describe rs nginx-rs

重点查看 Events。

可能原因：

• Pod 模板 YAML 配置错误。
• 镜像不存在。
• 资源不足。
• 节点调度失败。
• 配额限制。

2. ReplicaSet 副本数量始终不正确#

例如：

1
DESIRED   CURRENT   READY
2
3         5         5

可能原因：

Selector 匹配到了其他未被控制器认领的 Pod。

也可能是多个控制器的标签选择范围设计不合理。

检查：

1
kubectl get pods --show-labels

检查 ReplicaSet 的选择器：

1
kubectl get rs nginx-rs -o yaml

3. Pod 不断被创建和删除#

重点检查：

• 是否存在多个 ReplicaSet 使用重叠的 Selector。
• 是否存在其他控制器管理相同标签的 Pod。
• 是否有手动修改标签的行为。
• 是否有其他自动化程序修改副本数。

生产环境中应避免多个控制器对同一批 Pod 形成重叠管理。

16. 常用命令#

1. Deployment 命令#

建议把下面这些命令练到不需要查阅文档就能使用。

特别注意：

1
kubectl rollout restart deployment nginx

它会触发 Pod 模板的重启更新，使 Pod 逐步重新创建，但不会改变镜像版本。

2. ReplicaSet 命令与级联删除#

注意删除 ReplicaSet 时，默认会级联删除它管理的 Pod。如果只想删除 ReplicaSet、保留 Pod，可以使用：

1
kubectl delete rs nginx-rs --cascade=orphan

17. 知识检查清单#

Deployment 知识结构

flowchart LR
    N0["Deployment<br/>无状态应用部署控制器"]
    N1["副本管理<br/>replicas<br/>scale"]
    N2["更新策略<br/>RollingUpdate<br/>Recreate"]
    N3["发布控制<br/>pause / resume<br/>progressDeadlineSeconds"]
    N4["版本管理<br/>Revision<br/>rollout undo"]
    N0 --> N1
    N0 --> N2
    N0 --> N3
    N0 --> N4

ReplicaSet 核心知识

1. ReplicaSet 用于维护 Pod 副本数量。
2. 通过 Selector 选择和管理 Pod。
3. 通过 Template 创建新的 Pod。
4. 通过控制循环不断协调实际状态与期望状态。
5. 通过 OwnerReference 建立资源所属关系。
6. ReplicaSet 可以认领符合条件且尚未被其他控制器认领的 Pod。
7. Deployment 通常通过 ReplicaSet 实现应用发布与版本管理。