Kubernetes 的设计理念是：
用单一职责的组件，通过对象组合的方式，构建出复杂且可扩展的分布式系统。
什么是“单一职责”和“对象组合”？
这两个概念来自软件设计原则（尤其是微服务与面向对象设计），Kubernetes 只是将它们贯彻得非常彻底：
| 概念 | 含义 | 在 K8s 中的体现 |
|---|---|---|
| 单一职责（Single Responsibility） | 每个组件、对象、控制器只做一件事情，并把它做到极致 | API Server 只提供 API；Scheduler 只负责调度；Controller 只负责某个资源的控制循环 |
| 对象组合（Object Composition） | 复杂功能通过多个简单对象的组合实现，而不是通过单个复杂对象 | Pod 由多个 Container 组成；Deployment 由多个 ReplicaSet 组成；Service 与 Pod 组合形成负载均衡能力 |
Kubernetes 的单一职责原则
K8s 的每个核心组件都有明确且边界清晰的职责：
| 组件 | 职责 |
|---|---|
| kube-apiserver | 提供 REST API，是所有操作的入口，不做任何业务逻辑，只负责一致性与认证授权 |
| kube-scheduler | 只负责选择 Pod 要运行在哪个 Node 上 |
| kube-controller-manager | 负责运行各种控制循环（ReplicaSetController、NodeController、ServiceController 等），每个控制器专注一种资源类型 |
| kubelet | 只负责本节点 Pod 的生命周期管理 |
| etcd | 只负责存储状态，不参与逻辑 |
👉 这就像一个分布式的微内核系统——每个模块专注于自己的“单一职责”，彼此通过 API 协作。
对象组合的体现（K8s 的“积木哲学”）
Kubernetes 的对象设计体现出非常强的组合思想（composition over inheritance）：
Pod 是容器的组合
- 一个 Pod 中可以组合多个容器（共享网络、存储命名空间）。
- 比如一个主容器 + 一个 sidecar 容器（如日志收集、代理）。
- Pod 本身不关心容器内部细节，只定义组合关系。
高层对象是底层对象的组合
- ReplicaSet 组合多个 Pod，保证副本数；
- Deployment 组合 ReplicaSet，实现滚动升级；
- Service 组合 Pod 提供稳定访问入口；
- Ingress 组合多个 Service 提供统一的 HTTP 入口。
这种“对象套对象”的层级组合，让系统具有高度的模块化与可替换性。
控制循环（Controller Loop）是组合逻辑的胶水
控制器是 Kubernetes 实现组合逻辑的“胶水层”：
- 控制器通过 Watch API 观察对象状态；
- 检查“期望状态”（spec）与“实际状态”（status）；
- 通过创建/删除其他对象来组合出目标效果。
例如：
- Deployment Controller 不直接操作容器；
- 它只是创建 ReplicaSet → ReplicaSet 再创建 Pod → Pod 由 kubelet 管理；
- 各层各司其职，却形成一个完整的生命周期管理流程。
这就是组合带来的解耦与扩展性：你可以替换其中任意层（例如自定义控制器），而不破坏整体系统。
这种设计的优势：
| 特性 | 原因 |
|---|---|
| 高扩展性 | 新对象和控制器可以独立增加，不破坏现有体系 |
| 高可维护性 | 每个对象逻辑简单，易于调试和替换 |
| 强复用性 | 通用对象（Pod、ConfigMap）可以在不同系统中复用 |
| 一致性与声明式管理 | 所有对象都遵循相同的 API 模式（spec/status） |