Kubernetes 控制器（Controllers）对比表格
Nexmoe 2025年6月26日
在 Kubernetes 中，控制器（Controllers）是用于管理 Pod 生命周期的核心组件。每种控制器都有其特定的使用场景和功能特点。以下是主要控制器类型的详细对比。
控制器对比表格
| 特性维度 | Deployment | StatefulSet | DaemonSet | Job |
|---|---|---|---|---|
| 核心用途 | 管理无状态应用（Web 服务，API） | 管理有状态应用（数据库，消息队列） | 在每个节点运行守护进程（监控，日志） | 运行一次性批处理任务 |
| 应用状态 | 无状态 | 有状态 | 通常无状态 | 通常无状态 |
| Pod 身份 | 无固定身份，可任意替换 | 无论怎么调度，每个 Pod 都有一个永久不变的 ID | 与节点绑定 | 临时身份 |
| 存储管理 | 不需要持久化存储，可使用临时卷 | 需要稳定的持久化存储（通过 PV/PVC 动态或静态供应） | 可选，通常访问主机路径（HostPath）或使用临时存储 | 通常不需要，可按需挂载卷 |
| 部署与扩缩容 | 无序部署，支持水平扩缩容 | 有序、逐一地部署、扩缩容和删除（0, 1, 2…） | 自动部署到新加入的节点，随节点数增减 | 控制并行度（parallelism）和完成次数（completions），运行至完成 |
| 更新策略 | 滚动更新（RollingUpdate）、重建（Recreate）。可配置 maxSurge 和 maxUnavailable | 滚动更新（RollingUpdate），支持分区更新（partition）和按需更新（OnDelete） | 滚动更新（RollingUpdate）、按需更新（OnDelete） | 不适用，Job 一旦创建，其 Pod 模板不可变 |
| 回滚机制 | 支持自动回滚到历史版本（revisionHistoryLimit） | 不直接支持，需要手动操作或外部工具 | 支持回滚 | 不适用 |
| 故障处理 | 自动重启或重建失败的 Pod | 具有相同身份的 Pod 最多只能有一个正在运行，但需手动干预恢复 | 节点故障时，该节点上的 Pod 随之消失；当节点恢复或有新节点加入时自动创建 Pod | 可配置失败重试次数（backoffLimit） |
| 关键特性 | 声明式更新、版本控制与回滚、可暂停/恢复部署 | 有序性、稳定的网络和存储、Headless Service 支持 | 节点亲和性、自动部署到新节点、可容忍污点 | 失败重试、并行执行、完成后自动清理（TTL） |
| 示例用例 | Nginx、Tomcat、NodeJS 应用 | MySQL、Redis、Kafka、ETCD | Fluentd、Prometheus Node Exporter、网络插件 | 数据迁移、批量计算、备份、ETL 任务 |
| 最佳实践 | 默认选择，适用于多数无状态应用 | 仅在需要稳定身份或有序操作时使用 | 用于基础设施和节点级服务 | 用于会终止的任务，非守护进程 |
控制器层级关系
Deployment → ReplicaSet → Pod：这是管理无状态应用最常用的模式。用户直接操作 Deployment 对象来声明应用的期望状态（例如，镜像版本、副本数）。Deployment 控制器自身不直接管理 Pod，而是通过创建和管理 ReplicaSet 来实现。当用户更新 Deployment 时（例如，升级应用），Deployment 会创建一个新的 ReplicaSet，并以受控的方式（如滚动更新）将 Pod 从旧的 ReplicaSet 迁移到新的 ReplicaSet。这使得版本控制和回滚成为可能，而 ReplicaSet 只需关注维持指定数量的 Pod 副本这一单一职责。可以说，Deployment 为 ReplicaSet 赋予了声明式更新和历史版本管理的能力。
CronJob → Job → Pod：CronJob 负责按预定的时间表（Cron 表达式）创建 Job 对象。Job 则负责执行一次性的任务，它会创建一个或多个 Pod 来完成具体工作，并确保它们成功终止。CronJob 本身不管理 Pod，它只关心在正确的时间点触发 Job。这种分层让定时任务的管理和实际任务的执行逻辑分离开来。
而 StatefulSet 和 DaemonSet 则直接管理 Pod，它们没有中间层的控制器，因为它们提供的 Pod 管理逻辑（如稳定身份、节点绑定）是它们自身的核心功能，不需要通过其他控制器来抽象。