1、ReplicaSet（RS）
ReplicaSet（简称 RS）是 Kubernetes 中负责Pod 副本数量保障的核心控制器，核心职责是持续监控集群中运行的 Pod 数量，确保与配置的期望副本数完全一致：实际 Pod 数量少于期望值时自动创建补全，多于期望值时自动删除多余副本。
ReplicaSet 通过 selector.matchLabels 标签选择器匹配并关联 Pod，仅管理带有对应标签的 Pod；Pod 模板中的标签必须与选择器标签严格一致，否则会出现配置异常，无法正常管理副本。
生产环境中不建议直接创建和使用 ReplicaSet。RS 本身仅具备副本数量管控能力，不支持滚动更新、版本历史记录、版本回退等高级发布功能，直接使用难以支撑业务迭代。日常运维中，RS 通常作为 Deployment 的底层控制单元，由 Deployment 统一管理，用户无需直接操作 RS。
apiVersion: apps/v1
kind: ReplicaSet
metadata:
labels:
app: webcluster
name: webcluster
spec:
replicas: 2 #期望副本数
selector:
matchLabels:
app: webcluster #标签选择器，匹配pod标签
template:
metadata:
labels:
app: webcluster #pod模板标签，必须匹配selector
spec:
containers:
- image: myapp:v1
name: myapp
kubectl apply -f repset.yml
#扩缩容
kubectl scale replicaset webcluster --replicas 4
kubectl scale replicaset webcluster --replicas 0
通过
kubectl scale可快速调整 RS 的期望副本数，将副本数设为 0 即可清空该 RS 下所有运行中的 Pod。需要注意：直接修改 RS 的镜像或配置，仅会影响后续新建的 Pod，已存在的旧 Pod 不会自动更新，无法实现平滑升级，这也是生产环境优先使用 Deployment 的核心原因。
2、Deployment（最常用无状态应用控制器）
Deployment 是构建在 ReplicaSet 之上的高层级控制器，是 Kubernetes 中无状态应用部署的标准方案。它通过管理多个版本的 ReplicaSet 来实现应用的滚动更新、版本回退、发布暂停与恢复等高级能力，全程保证服务可用性，实现业务无感升级。
Deployment 核心工作原理：每次更新 Pod 模板（如镜像版本、环境变量、资源配置等），都会自动生成一个全新的 ReplicaSet 版本；更新过程中逐步提升新版本 RS 的副本数，同时降低旧版本 RS 的副本数，旧版本 RS 会被保留，用于后续版本回退。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: webcluster
name: webcluster
spec:
minReadySeconds: 5 #pod就绪后等待多久视为可用
replicas: 2
selector:
matchLabels:
app: webcluster
#滚动更新策略
strategy:
rollingUpdate:
maxSurge: 1 #最多可以比期望副本多几个pod
maxUnavailable: 0 #最多允许多少pod不可用
template:
metadata:
labels:
app: webcluster
spec:
containers:
- image: myapp:v1
name: myapp
kubectl apply -f dep.yml
#暴露服务
kubectl expose deployment webcluster --port 80 --target-port 80
#查看更新策略
kubectl describe deployments.apps webcluster
3、DaemonSet
DaemonSet 是节点级别的控制器，核心特性是在每一个符合条件的节点上运行且仅运行一个 Pod 副本。当新节点加入集群时，会自动在该节点上创建对应 Pod；当节点从集群移除时，对应 Pod 会被自动清理，无需手动管理副本数量。
DaemonSet 非常适合部署节点级别的基础设施组件，典型场景包括：日志采集代理（如 Filebeat、Fluentd）、节点监控指标采集器（如 Node Exporter）、集群网络插件、存储客户端插件等。这类组件需要覆盖所有或指定节点，随节点生命周期自动运维。
可以通过 nodeSelector、节点亲和性、污点容忍等配置，控制 DaemonSet 仅在特定标签的节点上运行，实现按需部署，例如仅在 GPU 节点部署 GPU 监控组件。
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
4、Job 控制器（一次性任务）
Job 是专门用于管理一次性、批处理类任务的控制器，与 Deployment 这类常驻服务型控制器不同，Job 管理的 Pod 执行完成后就会正常退出，不会持续运行。其核心目标是保证指定数量的 Pod 成功执行完成，最终标记任务结束。
apiVersion: batch/v1
kind: Job
metadata:
name: testjob
spec:
completions: 6 #一共要成功完成6个pod
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
kubectl apply -f job.yml
#查看任务输出日志
kubectl logs pods/testjob-4cdlr
5、CronJob 定时任务控制器CronJob 是在 Job 基础上扩展的定时任务控制器，类似 Linux 系统的 crontab，按照指定的 Cron 时间表达式周期性地自动创建 Job 并执行任务，适用于定时备份、定时报表、定时数据清理、定时巡检等周期性场景。
apiVersion: batch/v1
kind: CronJob
metadata:
name: cronjob
spec:
schedule: '* * * * *' #cron表达式，每分钟执行
jobTemplate:
metadata:
name: cronjob
spec:
template:
spec:
containers:
- image: busybox
name: cronjob
command:
/bin/sh
-c
echo "hello timinglee"
restartPolicy: OnFailure
kubectl apply -f cronjob.yml
kubectl get cronjobs.batch
kubectl logs cronjob-29598241-pxggh
总结
本文围绕 Kubernetes 核心工作负载控制器展开，系统介绍了 ReplicaSet、Deployment、DaemonSet、Job、CronJob 五大常用控制器的功能定位、配置逻辑与适用场景。
控制器是 Kubernetes 实现应用自动化运维的核心载体，替代人工完成 Pod 的创建、自愈、扩缩容、发布与全生命周期管理。其中 Deployment 基于 ReplicaSet 实现无状态应用的滚动发布与版本回退，是日常业务部署的首选方案；DaemonSet 适配节点级常驻组件的全域自动部署；Job 与 CronJob 则分别覆盖一次性批处理与周期性定时任务场景。
掌握不同控制器的特性与选型逻辑，能够针对无状态服务、基础设施组件、批处理任务等不同业务场景选择最优部署方案，是 Kubernetes 应用编排与集群运维的核心基础，也是后续学习有状态服务、自动扩缩容等进阶能力的前提。