核心概念：Pod 是调度的最小单位

Kubernetes 不直接管理容器，而是管理 Pod。Pod 是最小的可部署单元，可以包含一个或多个紧密耦合的容器（共享网络、存储、IPC 命名空间）。调度器（kube-scheduler）负责根据资源请求、约束、亲和性/反亲和性规则等，将新创建的 Pod 放置（Place） 到集群中合适的 Node 上运行。

控制器（Controller）：确保期望状态

Kubernetes 的核心哲学之一是声明式管理：你声明你想要的系统状态（Desired State），控制器负责检测当前状态（Current State）并驱动系统向期望状态收敛。对于 Pod 管理，有专门的控制器来确保特定数量的 Pod 副本在运行，处理 Pod 故障、节点故障等情况。

1. Replication Controller (RC) - 已弃用/被取代

   • 作用： 确保在任何时候都运行指定数量的完全相同的 Pod 副本。它是 Kubernetes 早期用于副本管理的主要控制器。

   • 工作原理：

     • 你定义一个 RC，指定 replicas（期望的 Pod 副本数）、selector（用于识别它管理的 Pod 的标签）和 template（用于创建新 Pod 的模板）。

     • RC 持续监控集群中匹配其 selector 的 Pod。

     • 如果实际运行的 Pod 数量少于 replicas，RC 会根据 template 创建新的 Pod。

     • 如果实际运行的 Pod 数量多于 replicas，RC 会删除多余的 Pod（通常基于创建时间）。

     • 如果 Pod 失败、被删除或所在的 Node 不可达，RC 会检测到 Pod 缺失并创建新的 Pod 来替代它。

   • 缺点/被取代原因：

     • 标签选择器不够灵活： RC 的 selector 只支持基于等值的匹配（=），不支持基于集合（in, notin, exists）的更复杂选择。

     • 功能单一： 没有内置的滚动更新策略。

   • 现状： 强烈建议不要使用。它已被更强大的 ReplicaSet 取代。了解它主要是为了理解历史和发展。

2. ReplicaSet (RS) - RC 的进化版

   • 作用： 与 RC 完全相同：确保指定数量的完全相同的 Pod 副本持续运行。它是 RC 的替代品。

   • 工作原理： 与 RC 基本一致，核心区别在于 selector。

   • 改进点：

     • 更强大的标签选择器： RS 使用基于集合的标签选择器 (matchLabels, matchExpressions)，允许更灵活、更精确地选择 Pod（例如 app=frontend, environment in (production, staging)）。

   • 直接使用场景： 虽然 RS 功能完整，但通常不直接创建 RS。为什么？

     • Deployment 的基石： RS 是 Deployment 控制器实现滚动更新和回滚的核心组件。Deployment 为你管理 RS。

   • 何时直接使用 RS？ 当你需要确保一组完全相同的 Pod 始终运行，但不需要 Deployment 提供的滚动更新、版本历史记录等功能时（这种情况比较少见）。

工作负载类型与对应控制器

控制器不仅管理副本数，还针对不同类型的应用负载提供了特定的语义和管理能力：

1. 无状态应用 (Stateless Applications)

   • 特点：

     • 每个 Pod 实例完全相同、可互换（幂等性）。

     • 不依赖本地持久化存储（状态保存在外部数据库、缓存等）。

     • 启动顺序无关紧要。

     • 水平扩展简单（加副本即可）。

     • 典型例子：Web 服务器前端、API 服务、无状态微服务。

   • 首选控制器：Deployment

     • 基于 ReplicaSet： Deployment 在 ReplicaSet 之上构建。

     • 核心价值：声明式更新 & 回滚：

       • 你只需要更新 Deployment 的 Pod 模板（例如，容器镜像版本）。

       • Deployment 会自动创建一个新的 ReplicaSet。

       • 然后以受控方式（例如滚动更新 - RollingUpdate）将 Pod 从旧的 RS 迁移到新的 RS（逐步停止旧 Pod，启动新 Pod）。

       • 如果更新后出现问题，你可以轻松地回滚到 Deployment 之前的任一修订版本。

     • 管理 ReplicaSet 历史： 保留旧的 RS 以便回滚（默认保留修订数量可配置）。

     • 简化操作： 只需操作 Deployment 对象，它替你管理底层 RS 和 Pod。

   • 总结： Deployment = ReplicaSet + 声明式滚动更新 + 版本历史 + 回滚。这是部署和管理无状态应用的标准方式。

2. 有状态应用 (Stateful Applications)

   • 特点：

     • 每个 Pod 实例是唯一且不可互换的，通常有稳定的标识符（如主机名、序号）。

     • 需要稳定的、持久的存储（每个 Pod 实例通常需要自己专属的 PersistentVolume）。

     • 启动、停止、扩展、更新需要有序性（例如，数据库主从：主库要先启动并运行，从库才能启动并连接主库进行复制）。

     • 网络标识需要稳定（稳定的 DNS 主机名）。

     • 典型例子：数据库（MySQL, PostgreSQL, MongoDB 集群）、分布式存储（ZooKeeper, etcd, Elasticsearch 数据节点）、消息队列（Kafka brokers）。

   • 首选控制器：StatefulSet

     • 核心特性：

       • 稳定的网络标识： 为每个 Pod 分配一个序号索引（0, 1, 2, ...）和基于该索引的稳定主机名（<statefulset-name>-<ordinal-index>）。提供稳定的 DNS 记录（<pod-name>.<svc-name>.<namespace>.svc.cluster.local）。

       • 稳定的持久化存储： 使用 volumeClaimTemplates。为 StatefulSet 创建的每个 Pod 自动生成一个唯一的 PersistentVolumeClaim (PVC)。即使 Pod 被重新调度到其他节点，它也能挂载回同一个 PV（数据持久化）。

       • 有序部署/扩展： 默认情况下，Pod 按顺序创建（0, 1, 2...）、终止（逆序...2, 1, 0）、更新（逆序）。

       • 有序滚动更新： 更新策略可以配置为有序（OnDelete 或 RollingUpdate）。

     • 总结： StatefulSet 为需要稳定标识符、持久存储和有序部署/扩展/更新的有状态应用提供了必要的保障。这是部署和管理有状态服务的标准方式。

3. 守护进程 (Daemons)

   • 特点：

     • 需要在集群的每个（或满足条件的）Node 上运行且仅运行一个副本的 Pod。

     • 通常提供节点级别的核心基础设施服务。

     • 当新 Node 加入集群时，Daemon Pod 应自动在该 Node 上启动；当 Node 被移除时，其上的 Daemon Pod 应被回收。

     • 典型例子：存储驱动（glusterd, ceph）、网络插件（flannel, calico）、日志收集器（fluentd, filebeat）、监控代理（node-exporter, datadog-agent）。

   • 首选控制器：DaemonSet

     • 工作原理：

       • 你定义一个 DaemonSet 和一个 Pod 模板。

       • DaemonSet 控制器确保所有（或通过 nodeSelector/affinity 选中的）Node 上都有且只有一个与该模板匹配的 Pod 实例在运行。

       • 当 Node 加入集群时，DaemonSet 会立即在该 Node 上调度一个 Pod。

       • 当 Node 从集群中移除（或不再满足选择条件）时，其上的 DaemonSet Pod 会被回收。

       • 如果 DaemonSet Pod 被删除或终止，控制器会在同一 Node 上创建一个新的替代 Pod。

     • 更新： 支持滚动更新 (RollingUpdate) 和删除更新 (OnDelete) 策略。

     • 总结： DaemonSet 确保集群中符合条件的所有 Node 上都运行一个指定的 Pod 副本。用于部署节点级别的“守护进程”服务。

4. 定时任务/批处理作业 (Scheduled Jobs / Batch Jobs)

   • 特点：

     • 执行一次性或周期性的任务。

     • 任务运行完成后，Pod 预期会退出（成功或失败）。

     • 不需要像 Deployment 那样持续运行副本。

     • 需要跟踪任务完成状态（成功、失败）。

     • 典型例子：数据库备份、发送通知邮件、生成每日报表、运行 CI/CD 流水线中的一个步骤。

   • 相关控制器：

     • Job：

       • 用于运行一次性任务直至成功完成。

       • 创建一个或多个 Pod（可并行运行多个 Pod 以加速任务）。

       • 确保指定数量的 Pod 成功终止（completions）。

       • 支持并行度控制（parallelism）。

       • 如果 Pod 失败（非零退出码），Job 会根据重启策略（OnFailure 或 Never）创建新的 Pod 重试任务，直到达到重试次数限制（backoffLimit）或成功完成。

     • CronJob：

       • 在 Job 之上构建。

       • 用于运行周期性的任务。

       • 你定义一个类似 Cron 表达式的时间表（例如 "0 * * * *" 表示每小时整点）。

       • 根据时间表，CronJob 控制器会自动创建新的 Job 对象来执行任务。

       • 管理 Job 的历史记录（成功/失败），可配置保留的成功/失败 Job 数量。

   • 总结：

     • 用 Job 运行一次性任务直到完成。

     • 用 CronJob 按照时间表（Cron 表达式）定期运行 Job。

总结表

关键点回顾：

1. 调度器 (kube-scheduler) 负责将新创建的 Pod 放置到合适的 Node 上。

2. 控制器 负责监控集群状态（实际状态）并驱动其向用户声明的期望状态收敛，确保 Pod 的副本数、运行位置、生命周期符合预期。

3. 选择正确的控制器取决于你的应用的特性（无状态 vs. 有状态）和运行模式（持续服务 vs. 守护进程 vs. 定时/一次性任务）。

4. Deployment 是无状态应用的黄金标准。

5. StatefulSet 是部署有状态服务的必备工具。

6. DaemonSet 用于节点级别的守护进程。

7. Job 和 CronJob 处理批处理和定时任务。

8. Replication Controller (RC) 已过时，被 ReplicaSet (RS) 取代，而 RS 通常由 Deployment 管理。