K8S控制器管理

Kubernetes 控制器完全指南：从 ReplicaSet 到 CronJob

一份涵盖 6 大控制器类型、50+ 实战操作的完整学习笔记

一、引言

在 Kubernetes 集群中，Pod 是最小的部署单元，但直接管理 Pod 并不是最佳实践。控制器（Controller） 是 Kubernetes 的"大脑"，它们负责确保集群的实际状态与期望状态一致，实现应用的自动化管理。

如果说 Pod 是 Kubernetes 的"士兵"，那么控制器就是"指挥官"。它们负责：

维持 Pod 的副本数量
执行滚动更新和版本回滚
确保每个节点运行特定的 Pod
管理一次性任务和定时任务

本文将从实际操作出发，完全基于真实的实验记录，带你全面掌握 Kubernetes 中 5 大核心控制器：

控制器	用途	适用场景
ReplicaSet	维护 Pod 副本数量	保证指定数量的 Pod 运行
Deployment	声明式应用更新	无状态应用的首选（最常用）
DaemonSet	每个节点运行一个 Pod	日志收集、监控、网络插件
Job	一次性任务	数据库迁移、批处理
CronJob	定时任务	定期备份、定时报表

环境说明：本文所有实验基于 Kubernetes v1.35.7 集群，包含 1 个 Master 节点和多个 Worker 节点，使用 Flannel 作为网络插件，Harbor 作为私有镜像仓库。

二、ReplicaSet 控制器

ReplicaSet 是 Kubernetes 中最基础的副本控制器，它的职责很简单：确保集群中始终运行指定数量的 Pod 副本。

💡 历史背景：ReplicaSet 是 ReplicationController 的升级版，支持更灵活的标签选择器。虽然 ReplicaSet 可以独立使用，但在生产环境中，我们通常使用更高级的 Deployment 来间接管理 ReplicaSet。

2.1 建立 ReplicaSet 控制器

生成 YAML 模板：

bash 复制代码

[root@master controller]# kubectl create deployment webcluster --image myapp:v1 --dry-run=client -o yaml > replicaset.yml

编辑 YAML 文件，将 kind 改为 ReplicaSet：

bash 复制代码

[root@master controller]# vim repset.yml

yaml 复制代码

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: webcluster
  name: webcluster
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webcluster
  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v1
        name: myapp

应用配置：

bash 复制代码

[root@master controller]# kubectl apply -f replicaset.yml
replicaset.apps/webcluster created

在另一个终端中持续监控 Pod 状态：

bash 复制代码

[root@master ~]# watch -n 1 kubectl get pods --show-labels
Every 1.0s: kubectl get pods --show-labels     master: Sun Aug 30 20:32:05 2026

NAME               READY   STATUS    RESTARTS   AGE   LABELS
webcluster-7clf7   1/1     Running   0          13m   app=webcluster
webcluster-snk6t   1/1     Running   0          13m   app=webcluster

可以看到，ReplicaSet 自动创建了 2 个 Pod，并且每个 Pod 都带有 app=webcluster 标签。

2.2 动态扩缩容

扩容到 4 个副本：

bash 复制代码

[root@master ~]# kubectl scale replicaset.apps webcluster --replicas 4
replicaset.apps/webcluster scaled

监控窗口立即显示新 Pod 被创建：

bash 复制代码

Every 1.0s: kubectl get pods --show-labels     master: Sun Aug 30 20:34:35 2026

NAME               READY   STATUS    RESTARTS   AGE   LABELS
webcluster-7clf7   1/1     Running   0          15m   app=webcluster
webcluster-fdb88   1/1     Running   0          24s   app=webcluster
webcluster-lmqdp   1/1     Running   0          24s   app=webcluster
webcluster-snk6t   1/1     Running   0          15m   app=webcluster

缩容到 2 个副本：

bash 复制代码

[root@master ~]# kubectl scale replicaset.apps webcluster --replicas 2
replicaset.apps/webcluster scaled

缩容到 0 个副本（清理所有 Pod）：

bash 复制代码

[root@master controller]# kubectl scale replicaset.apps webcluster --replicas 0
replicaset.apps/webcluster scaled

2.3 通过 YAML 更新副本数

我们也可以通过修改 YAML 文件并重新 apply 来实现扩缩容：

bash 复制代码

[root@master controller]# vim replicaset.yml

yaml 复制代码

spec:
  replicas: 2

bash 复制代码

[root@master controller]# kubectl apply -f replicaset.yml
replicaset.apps/webcluster configured

监控窗口显示 Pod 数量从 0 变为 2：

bash 复制代码

Every 1.0s: kubectl get pods --show-labels     master: Sun Aug 30 20:38:13 2026

NAME               READY   STATUS    RESTARTS   AGE   LABELS
webcluster-gln4w   1/1     Running   0          58s   app=webcluster
webcluster-th5p5   1/1     Running   0          58s   app=webcluster

📊 ReplicaSet 工作原理解析：

当修改 replicas 字段后，ReplicaSet 控制器会对比当前 Pod 数量和期望数量，然后创建或删除 Pod 以达到期望状态。

ReplicaSet 的核心机制：

通过标签选择器（selector）识别自己管理的 Pod
持续监控 Pod 数量，确保与 replicas 一致
当 Pod 意外删除时，自动重建

三、Deployment 控制器

Deployment 是 Kubernetes 中最常用、最重要的控制器。它在 ReplicaSet 的基础上，增加了滚动更新 、版本回滚 、更新暂停与恢复等高级功能。

3.1 建立 Deployment 并监控

设置监控命令（一个窗口同时查看 Pod 和 ReplicaSet）：

bash 复制代码

[root@master ~]# watch -n 1 "kubectl get pods --show-labels;echo ====;kubectl get replicasets.apps"
Every 1.0s: kubectl get pods --show-labels...  master: Sun Aug 30 20:50:44 2026

No resources found in default namespace.
====
No resources found in default namespace.

创建 Deployment YAML：

bash 复制代码

[root@master controller]# kubectl create deployment webcluster --image myapp:v1 --dry-run=client -o yaml > deployment.yml

bash 复制代码

[root@master controller]# vim dep.yml

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webcluster
  name: webcluster
spec:
  minReadySeconds: 5
  replicas: 2
  selector:
    matchLabels:
      app: webcluster
  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v1
        name: myapp

应用配置：

bash 复制代码

[root@master controller]# kubectl apply -f deployment.yml
deployment.apps/webcluster created

监控输出：

bash 复制代码

Every 1.0s: kubectl get pods --show-labels...  master: Sun Aug 30 20:54:42 2026

NAME                          READY   STATUS    RESTARTS   AGE   LABELS
webcluster-77c87d9946-dgjwx   1/1     Running   0          23s   app=webcluster
,pod-template-hash=77c87d9946
webcluster-77c87d9946-gs6h8   1/1     Running   0          23s   app=webcluster
,pod-template-hash=77c87d9946
====
NAME                    DESIRED   CURRENT   READY   AGE
webcluster-77c87d9946   2         2         2       23s

注意到 Deployment 自动创建了一个 ReplicaSet（名称后缀为 77c87d9946），该 ReplicaSet 管理着 2 个 Pod。

暴露服务以便后续测试：

bash 复制代码

[root@master controller]# kubectl expose deployment webcluster --port 80 --target-port 80
service/webcluster exposed


[root@master controller]# kubectl describe service webcluster
Name:                     webcluster
Namespace:                default
Labels:                   app=webcluster
Annotations:              <none>
Selector:                 app=webcluster
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.102.194.171
IPs:                      10.102.194.171
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
Endpoints:                10.244.1.12:80,10.244.2.8:80
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>


[root@master controller]# curl 10.102.194.171
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

3.2 升级和回滚

升级到 v2 版本：

修改 YAML 文件中的镜像版本：

bash 复制代码

[root@master controller]# vim deployment.yml

yaml 复制代码

spec:
  containers:
  - image: myapp:v2   # 从 v1 改为 v2
    name: myapp

bash 复制代码

[root@master controller]# kubectl apply -f deployment.yml
deployment.apps/webcluster configured


[root@master controller]# curl  10.102.194.171
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

回滚到 v1 版本：

bash 复制代码

[root@master controller]# vim deployment.yml

yaml 复制代码

spec:
  containers:
  - image: myapp:v1   # 改回 v1
    name: myapp

bash 复制代码

[root@master controller]# kubectl apply -f deployment.yml
deployment.apps/webcluster configured


Every 1.0s: kubectl get pods --show-labels...  master: Sun Aug 30 21:03:50 2026

NAME                          READY   STATUS    RESTARTS   AGE   LABELS
webcluster-6c8b4bb9d7-5sg9v   1/1     Running   0          99s   app=webcluster
,pod-template-hash=6c8b4bb9d7
webcluster-6c8b4bb9d7-67pdx   1/1     Running   0          92s   app=webcluster
,pod-template-hash=6c8b4bb9d7
webcluster-77c87d9946-fx8m9   1/1     Running   0          5s    app=webcluster
,pod-template-hash=77c87d9946
====
NAME                    DESIRED   CURRENT   READY   AGE
webcluster-6c8b4bb9d7   2         2         2       99s
webcluster-77c87d9946   1         1         1       9m31s


Every 1.0s: kubectl get pods --show-labels...  master: Sun Aug 30 21:04:26 2026

NAME                          READY   STATUS    RESTARTS   AGE   LABELS
webcluster-77c87d9946-f27dj   1/1     Running   0          34s   app=webcluster
,pod-template-hash=77c87d9946
webcluster-77c87d9946-fx8m9   1/1     Running   0          41s   app=webcluster
,pod-template-hash=77c87d9946
====
NAME                    DESIRED   CURRENT   READY   AGE
webcluster-6c8b4bb9d7   0         0         0       2m15s
webcluster-77c87d9946   2         2         2       10m


[root@master controller]# curl  10.102.194.171
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

🔄 更新机制：每次更新 Deployment，都会创建一个新的 ReplicaSet，并逐步将旧 ReplicaSet 的 Pod 替换为新 ReplicaSet 的 Pod。这就是滚动更新的核心原理。

四、版本更新管理及优化

在生产环境中，我们需要精细控制更新过程，确保业务零宕机。本节将深入 Deployment 的更新策略。

4.1 扩容以便观察更新过程

将副本数从 2 扩容到 6，便于观察滚动更新的细节：

bash 复制代码

[root@master controller]# vim deployment.yml

yaml 复制代码

spec:
  replicas: 6   # 从 2 改为 6

bash 复制代码

[root@master controller]# kubectl scale deployment webcluster --replicas 6
deployment.apps/webcluster scaled

4.2 查看默认更新策略

bash 复制代码

[root@master controller]# kubectl describe deployment webcluster | grep -i strategy
StrategyType:           RollingUpdate
RollingUpdateStrategy:  25% max unavailable, 25% max surge

默认策略的含义：

maxSurge: 25%：更新时，Pod 总数最多可以超过期望值的 25%（对于 6 个副本，最多可以同时存在 7.5 个，取整为 8 个）
maxUnavailable: 25%：更新时，不可用的 Pod 最多占 25%（对于 6 个副本，最多允许 1.5 个不可用，取整为 2 个）

4.3 自定义更新策略

我们可以精细控制更新行为，实现更保守或更激进的更新策略。

bash 复制代码

[root@master controller]# vim deployment.yml

yaml 复制代码

spec:
  minReadySeconds: 5
  replicas: 6
  selector:
    matchLabels:
      app: webcluster
  strategy:
    rollingUpdate:
      maxSurge: 1          # 更新时最多比期望值多 1 个 Pod
      maxUnavailable: 0    # 不允许有不可用的 Pod
  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v1
        name: myapp

bash 复制代码

[root@master controller]# kubectl apply -f deployment.yml
deployment.apps/webcluster configured

这个配置的意义：

maxUnavailable: 0：确保任何时候都有 6 个可用的 Pod，零宕机
maxSurge: 1：每次只额外创建 1 个新 Pod，资源消耗最低

4.4 更新暂停和恢复

在某些场景下，我们需要先暂停更新，进行验证或配置调整，然后再恢复更新。

查看当前部署历史：

bash 复制代码

[root@master controller]# kubectl rollout history deployment webcluster
deployment.apps/webcluster
REVISION  CHANGE-CAUSE
1         <none>

暂停更新：

bash 复制代码

[root@master controller]# kubectl rollout pause deployment webcluster
deployment.apps/webcluster paused

修改镜像版本（但更新不会立即执行）：

bash 复制代码

[root@master controller]# vim deployment.yml

yaml 复制代码

spec:
  containers:
  - image: myapp:v2   # 改为 v2
    name: myapp

bash 复制代码

[root@master controller]# kubectl apply -f  deployment.yml
deployment.apps/webcluster configured

此时查看历史，发现没有产生新的 Revision，Pod 也没有变化：

bash 复制代码

[root@master controller]# kubectl rollout history deployment webcluster
deployment.apps/webcluster
REVISION  CHANGE-CAUSE
1         <none>

恢复更新：

bash 复制代码

[root@master controller]# kubectl rollout resume deployment webcluster
deployment.apps/webcluster resumed


Every 1.0s: kubectl get pods --show-labels...  master: Sun Aug 30 21:22:13 2026

NAME                          READY   STATUS    RESTARTS   AGE    LABELS
webcluster-6c8b4bb9d7-6fflb   1/1     Running   0          5s     app=webcluste
r,pod-template-hash=6c8b4bb9d7
webcluster-77c87d9946-6ml6v   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
webcluster-77c87d9946-cfl48   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
webcluster-77c87d9946-qc2pt   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
webcluster-77c87d9946-thgwr   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
webcluster-77c87d9946-tzc4x   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
webcluster-77c87d9946-v84lp   1/1     Running   0          7m5s   app=webcluste
r,pod-template-hash=77c87d9946
====
NAME                    DESIRED   CURRENT   READY   AGE
webcluster-6c8b4bb9d7   1         1         1       5s
webcluster-77c87d9946   6         6         6       7m5s

更新开始执行，产生新的 Revision：

bash 复制代码

[root@master controller]# kubectl rollout history deployment webcluster
deployment.apps/webcluster
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

💡 使用场景：暂停更新常用于金丝雀发布（Canary Release）场景。先暂停更新，将少量流量导入新版本验证，确认无问题后再恢复更新，逐步完成全量发布。

五、DaemonSet 控制器

DaemonSet 确保集群中的每个节点都运行一个 Pod 副本。当新节点加入集群时，DaemonSet 会自动在新节点上创建 Pod；当节点被移除时，对应的 Pod 也会被删除。

典型应用场景：

日志收集（如 Fluentd、Filebeat）
节点监控（如 Prometheus Node Exporter）
网络插件（如 Flannel、Calico）
存储插件（如 CSI 驱动）

5.1 创建 DaemonSet

bash 复制代码

[root@master controller]# kubectl create deployment daemonset --image myapp:v1 --dry-run=client -o yaml > daemonset.yml

修改为 DaemonSet 类型：

bash 复制代码

[root@master controller]# vim daemonset.yml

yaml 复制代码

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: daemonset
  name: daemonset
spec:
  selector:
    matchLabels:
      app: daemonset
  template:
    metadata:
      labels:
        app: daemonset
    spec:
      containers:
      - image: myapp:v1
        name: myapp

bash 复制代码

[root@master controller]# kubectl apply -f daemonset.yml
daemonset.apps/daemonset created

5.2 加入新节点，观察 DaemonSet 自动部署

在 Master 上生成新节点的加入命令：

bash 复制代码

[root@master controller]# kubeadm token create --print-join-command
kubeadm join 172.25.254.100:6443 --token f1njps.l4nsg4hzzjcrnejx --discovery-to ken-ca-cert-hash sha256:8f16da80cf42c9101daf2dc805c4fc6521a876b1de4da4d0b931536 646282a4f

在新节点（node3）上执行加入命令：

bash 复制代码

[root@node3 ~]# kubeadm join 172.25.254.100:6443 --token f1njps.l4nsg4hzzjcrnejx --discovery-token-ca-cert-hash sha256:8f16da80cf42c9101daf2dc805c4fc6521a876b1de4da4d0b931536646282a4f --cri-socket=unix:///var/run/cri-dockerd.sock
[preflight] Running pre-flight checks
        [WARNING SystemVerification]: kernel release 5.14.0-687.5.3.el9_8.x86_64 is unsupported. Supported LTS versions from the 5.x series are 5.4, 5.10 and 5.15. Any 6.x version is also supported. For cgroups v2 support, the recommended version is 5.10 or newer
[preflight] Reading configuration from the "kubeadm-config" ConfigMap in namespace "kube-system"...
[preflight] Use 'kubeadm init phase upload-config kubeadm --config your-config-file' to re-upload it.
W0830 22:13:52.568010   49516 configset.go:176] error unmarshaling configuration schema.GroupVersionKind{Group:"kubeproxy.config.k8s.io", Version:"v1alpha1", Kind:"KubeProxyConfiguration"}: strict decoding error: yaml: unmarshal errors:
  line 54: key "ipvs" already set in map
W0830 22:13:52.571743   49516 utils.go:69] The recommended value for "bindAddress" in "KubeProxyConfiguration" is: ::; the provided value is: 0.0.0.0
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 510.286099ms
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

观察 Pod 自动部署：

当 node3 加入集群后，DaemonSet 会自动在 node3 上创建 Pod，无需任何人工干预：

bash 复制代码

[root@master controller]# kubectl get pods -o wide
Every 1.0s: kubectl get pods -o wide            master: Sun Aug 30 22:14:52 2026

NAME              READY   STATUS    RESTARTS      AGE     IP            NODE
NOMINATED NODE   READINESS GATES
daemonset-b5f6l   1/1     Running   2 (18m ago)   43m     10.244.2.27   node2
<none>           <none>
daemonset-ptfdt   1/1     Running   2 (18m ago)   43m     10.244.1.31   node1
<none>           <none>
daemonset-vscqt   1/1     Running   0             8m13s   10.244.3.3    node3
<none>           <none>

每个节点上正好运行一个 DaemonSet Pod，完美体现了 DaemonSet 的核心特性。

六、Job 控制器

Job 控制器用于运行一次性任务。与长期运行的服务不同，Job 创建的 Pod 在任务完成后会正常退出，不会自动重启。

典型应用场景：

数据库迁移
数据批处理
初始化配置
数据备份

6.1 准备镜像

bash 复制代码

[root@master ~]# docker load -i perl-5.34.tar.gz
[root@master ~]# docker tag perl:5.34.0 reg.timinglee.org/library/perl:5.34.0
[root@master ~]# docker login reg.timinglee.org -u admin
Password:
Login Succeeded
[root@master ~]# docker push reg.timinglee.org/library/perl:5.34.0

6.2 创建 Job

bash 复制代码

[root@master controller]# kubectl create job job --image perl:5.34.0 --dry-run=client -o yaml > job.yml

bash 复制代码

[root@master controller]# vim job.yml

yaml 复制代码

apiVersion: batch/v1
kind: Job
metadata:
  name: testjob
spec:
  completions: 6      # 总共需要成功运行 6 次
  parallelism: 2      # 同时运行 2 个 Pod
  backoffLimit: 4     # 失败重试次数限制
  template:
    spec:
      containers:
      - image: busybox
        name: testjob
        command: ["/bin/sh", "-c"]
        args:
        - |
          echo this is testjob message
          sleep 10
      restartPolicy: Never

参数说明：

completions: 6：总共需要完成 6 个任务
parallelism: 2：同时运行 2 个 Pod 并行处理
backoffLimit: 4：如果 Pod 失败，最多重试 4 次
restartPolicy: Never：任务完成后不重启

应用配置并观察执行：

bash 复制代码

[root@master controller]# kubectl apply -f job.yml
job.batch/testjob created

[root@master controller]# watch -n 1 kubectl get pods -o wide
Every 1.0s: kubectl get pods -o wide           master: Sun Aug 30 22:37:50 2026

NAME            READY   STATUS      RESTARTS   AGE   IP            NODE    NOMI
NATED NODE   READINESS GATES
testjob-b24bg   0/1     Completed   0          16s   10.244.2.59   node2   <non
e>           <none>
testjob-kcnpw   1/1     Running     0          2s    10.244.2.60   node2   <non
e>           <none>
testjob-pfxp2   0/1     Completed   0          30s   10.244.2.57   node2   <non
e>           <none>
testjob-svznt   1/1     Running     0          2s    10.244.2.61   node2   <non
e>           <none>
testjob-t76v4   0/1     Completed   0          16s   10.244.2.58   node2   <non
e>           <none>
testjob-vp8fn   0/1     Completed   0          30s   10.244.2.56   node2   <non
e>           <none>

...

查看任务输出：

bash 复制代码

[root@master controller]# kubectl logs pods/testjob-vp8fn
this is testjob message

所有 Pod 完成任务后，Job 状态变为 Complete，Pod 保留以便查看日志。

七、CronJob 控制器

CronJob 基于 Job 构建，支持定时执行任务，类似于 Linux 的 Crontab。

典型应用场景：

定期数据备份
定时报表生成
定期清理过期数据
周期性健康检查

7.1 创建 CronJob

bash 复制代码

[root@master controller]# kubectl create cronjob cronjob --image busybox --schedule "* * * * *" --dry-run=client -o yaml > cronjob.yml

bash 复制代码

[root@master controller]# vim cronjob.yml

yaml 复制代码

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob
spec:
  jobTemplate:
    metadata:
      name: cronjob
    spec:
      template:
        spec:
          containers:
          - image: busybox
            name: cronjob
            command: ["/bin/sh","-c"]
            args:
            - echo "haha"
          restartPolicy: OnFailure
  schedule: '* * * * *'

⏰ Cron 表达式格式 ：分时日月周

* * * * * = 每分钟

0 * * * * = 每小时整点

0 2 * * * = 每天凌晨 2 点

0 2 * * 0 = 每周日凌晨 2 点

7.2 部署并观察执行

bash 复制代码

[root@master controller]# kubectl apply -f cronjob.yml
cronjob.batch/cronjob created

查看 CronJob 状态：

bash 复制代码

[root@master controller]# kubectl get cronjobs.batch
NAME      SCHEDULE    TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob   * * * * *   <none>     False     0        25s             2m2s

查看定时任务产生的 Pod：

bash 复制代码

[root@master controller]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
cronjob-29801687-fvghj   0/1     Completed   0          96s
cronjob-29801688-k9dv4   0/1     Completed   0          36s

查看任务输出：

bash 复制代码

[root@master controller]# kubectl logs cronjob-29801687-fvghj
haha

可以看到，CronJob 每分钟自动创建一个新的 Job，Job 再创建 Pod 执行任务，任务完成后 Pod 进入 Completed 状态。

八、控制器对比总结

特性	ReplicaSet	Deployment	DaemonSet	Job	CronJob
主要用途	维持副本数	无状态应用管理	每个节点运行一个	一次性任务	定时任务
滚动更新	❌	✅	✅（部分支持）	❌	❌
版本回滚	❌	✅	❌	❌	❌
更新策略控制	❌	✅	❌	❌	❌
Pod 生命周期	长期运行	长期运行	长期运行	完成后退出	定时创建
生产使用	间接使用	✅ 最常用	特定场景	批处理	定时作业

选择指南

无状态 Web 服务/API → 使用 Deployment
需要每个节点运行的守护进程 → 使用 DaemonSet
一次性数据迁移/初始化 → 使用 Job
定期备份/清理 → 使用 CronJob
不要直接使用 ReplicaSet，用 Deployment 替代

九、最佳实践

9.1 始终使用 Deployment 而非裸 Pod

yaml 复制代码

# ❌ 不推荐：直接创建 Pod
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - image: myapp:v1

yaml 复制代码

# ✅ 推荐：使用 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: myapp:v1

9.2 合理配置更新策略

yaml 复制代码

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1           # 保守策略：每次多建 1 个
      maxUnavailable: 0     # 零宕机更新
  minReadySeconds: 10       # 新 Pod 稳定运行 10 秒后才认为就绪

9.3 Job 设置合理的重试策略

yaml 复制代码

spec:
  backoffLimit: 3           # 最多重试 3 次
  activeDeadlineSeconds: 60 # 最多运行 60 秒

9.4 为 CronJob 设置并发策略

yaml 复制代码

spec:
  concurrencyPolicy: Forbid  # 禁止并发执行
  # 可选值：Allow（允许并发）、Forbid（禁止并发）、Replace（替换旧任务）

十、常用命令速查

操作	命令
查看 Deployment	`kubectl get deploy`
查看 ReplicaSet	`kubectl get rs`
查看 DaemonSet	`kubectl get ds`
查看 Job	`kubectl get job`
查看 CronJob	`kubectl get cj`
扩容/缩容	`kubectl scale deploy <name> --replicas=N`
滚动重启	`kubectl rollout restart deploy <name>`
查看历史	`kubectl rollout history deploy <name>`
回滚到上一版本	`kubectl rollout undo deploy <name>`
回滚到指定版本	`kubectl rollout undo deploy <name> --to-revision=N`
暂停更新	`kubectl rollout pause deploy <name>`
恢复更新	`kubectl rollout resume deploy <name>`
查看更新状态	`kubectl rollout status deploy <name>`

十一、结语

本文从零开始，通过 50+ 个实际操作，完整覆盖了 Kubernetes 中 6 大核心控制器的使用：

ReplicaSet --- 副本数量的守护者
Deployment --- 无状态应用的首选，支持滚动更新和回滚
DaemonSet --- 每个节点一个 Pod，适合监控和日志
Job --- 一次性任务
CronJob --- 定时任务

掌握这些控制器，你就掌握了 Kubernetes 应用管理的核心。在生产环境中，Deployment 是最常用的控制器，务必深入理解其更新策略、滚动更新机制和版本回滚能力。

Kubernetes 的控制器模式是其设计的精髓所在------通过声明式 API 和控制器循环，实现了"让世界按期望状态运转"的自动化管理理念。