一、 控制器概述与工作机制

1. 核心定义
   控制器是 Kubernetes 中管理 Pod 的核心中间层组件。相较于自主式 Pod（故障或退出后不会自动重建），控制器管理的 Pod 在其生命周期内始终维持用户声明的期望状态。
2. 工作原理

• • 声明式配置：用户仅需通过 YAML 声明期望的 Pod 数量、规格与标签，无需干预具体创建过程。
  • 状态调和（Reconciliation）：期望状态写入 etcd 后，APIServer 持续比对期望状态与集群当前状态。若发现偏差，控制循环将自动触发编排操作（创建、删除或重建），实现 Pod 的自愈与高可用。

二、 常用控制器类型及适用场景

控制器名称	核心用途与特性
ReplicationController	原始 Pod 控制器，功能已被 ReplicaSet 替代，现已废弃。
ReplicaSet	确保任意时刻均有指定数量的 Pod 副本运行；支持基于集合的标签选择器。通常作为 Deployment 的底层组件使用。
Deployment	为 Pod 和 ReplicaSet 提供声明式更新能力。适用于无状态应用的部署、滚动更新、扩缩容与回滚。
DaemonSet	确保在集群全部或指定节点上运行且仅运行一个 Pod 副本。常用于日志收集、监控代理、存储守护进程等节点级服务。
StatefulSet	专用于管理有状态应用，保障 Pod 的网络标识、存储卷及启动/停止顺序的稳定性。
Job	负责执行一次性批处理任务。记录成功结束的 Pod 数量，达到设定值后任务自动终止。
CronJob	基于时间调度（Cron 表达式）周期性创建 Job 任务，实现定时任务自动化。
HPA (Horizontal Pod Autoscaler)	根据 CPU/内存等资源利用率指标，自动调整 Service 关联的 Pod 副本数，实现水平弹性伸缩。

三、 核心控制器详解与配置规范

3.1 ReplicaSet 控制器

• 功能定位：维持指定数量的 Pod 副本，通过 selector.matchLabels 精确匹配并管理目标 Pod。
• 核心参数：

• • spec.replicas：声明期望的 Pod 副本数。
  • spec.selector.matchLabels：定义用于匹配 Pod 的键值对标签。
  • spec.template：Pod 模板，包含 metadata.labels 及容器运行时配置（镜像、名称等）。

• 运行机制：若手动修改 Pod 标签使其脱离匹配范围，ReplicaSet 将立即依据模板重建新 Pod；删除受管 Pod 后亦会自动触发重建。

3.2 Deployment 控制器（生产环境推荐）

• 架构设计：Deployment → 管理 ReplicaSet → 管理 Pod。每个版本迭代对应一个独立的 ReplicaSet。
• 核心能力：

• • 滚动更新（Rolling Update）：默认策略为 25% max unavailable, 25% max surge。更新时创建新版 RS，逐步替换旧版 RS 的 Pod，确保服务连续性。
  • 版本回滚：支持快速切换至历史 ReplicaSet，实现故障版本的安全回退。
  • 更新策略控制：

• • • minReadySeconds：Pod 标记为 Ready 后需持续运行的最短时间，确认稳定后再推进下一批更新。
    • maxSurge：允许超出期望副本数的最大数量（或百分比）。
    • maxUnavailable：允许处于不可用状态的最大数量（或百分比）。

• • 暂停与恢复（Pause & Resume）：通过 kubectl rollout pause 暂存多次配置变更，避免中间状态触发频繁发布；待变更全部就绪后执行 kubectl rollout resume 统一生效，保障生产环境变更安全。

3.3 DaemonSet 控制器

• 功能定位：全局或定向节点级守护进程部署。节点加入集群时自动调度 Pod，节点移除或控制器删除时自动清理。
• 典型场景：集群存储（glusterd/ceph）、日志采集（fluentd/logstash）、节点监控（Prometheus Node Exporter/Zabbix Agent）。
• 配置要点：通常需配置 tolerations 以容忍 Master 节点等带有污点（Taint）的节点，确保覆盖全集群。

3.4 Job 控制器

• 功能定位：执行短暂、一次性计算或批处理任务。
• 核心参数：

• • completions：任务需成功完成的 Pod 总数。
  • parallelism：单次并行执行的 Pod 数量。
  • backoffLimit：任务失败后的最大重试次数。
  • restartPolicy：仅支持 OnFailure 或 Never，不支持 Always。

• • • OnFailure：容器失败时原地重启，failed 计数不变。
    • Never：容器失败时创建新 Pod，原失败 Pod 保留，failed 计数加 1。

3.5 CronJob 控制器

• 功能定位：基于 Cron 表达式的时间调度器，周期性实例化 Job 对象。
• 核心结构：

• • schedule：时间调度规则（如 "* * * * *" 表示每分钟执行）。
  • jobTemplate：定义被周期性触发的 Job 模板，包含容器镜像、执行命令及重启策略。

• 适用场景：定时数据库备份、日志轮转清理、周期性数据同步与报表生成。

四、 常用运维操作命令规范

操作类型	命令示例
生成 YAML 模板	kubectl create deployment <name> --image <image> --dry-run=client -o yaml > <name>.yml
应用/更新配置	kubectl apply -f <file>.yml
查看 Pod 与标签	kubectl get pods --show-labels / kubectl get pods -o wide
查看控制器详情	kubectl describe deployments <name>
查看更新历史	kubectl rollout history deployment <name>
暂停/恢复更新	kubectl rollout pause/resume deployment <name>
删除控制器资源	kubectl delete -f <file>.yml

五、 总结

Kubernetes 控制器通过声明式 API 与控制循环机制，实现了工作负载的自动化编排与自愈。在实际生产环境中：

• 无状态服务优先采用 Deployment，充分利用其滚动更新、版本管理与暂停恢复能力。
• 节点级基础组件采用 DaemonSet 保障全局覆盖。
• 离线/定时任务分别依托 Job 与 CronJob 实现精准调度。
• 所有控制器均依赖 etcd 状态存储与标签选择器机制，合理设计标签规范与资源配额是保障集群稳定运行的基础。