一、控制平面组件（整体）
控制平面组件会为集群做出全局决策，比如资源的调度。以及检测和响应集群事件，例如当不满足 Deployment 的 replicas 字段时，要启动新的 Pod。
- 控制平面 = 集群的 "大脑 / 指挥部"
- 不干具体业务，只管整个集群 ：
- 决定 Pod 跑在哪台机器（调度）
- 时刻对比：你想要的状态 vs 实际状态
- 不一样就自动修正：
- 比如你要求 3 个 Pod，现在只有 2 个
- 控制平面就自动再启动 1 个
控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，安装脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。
- 理论上：大脑组件可以散在多台机器
- 实际学习 / 简单环境：
- 通常一台机器当 "主控节点"，专门跑控制平面
- 这台机器一般不跑你的业务容器，避免互相影响
请参阅使用 kubeadm 构建高可用性集群中关于跨多机器安装控制平面的示例。
- 生产环境要高可用，会把控制平面拆到多台机器，防止一台挂了整个集群崩。
二、kube-apiserver
API 服务器是 Kubernetes 控制平面的组件，该组件负责公开了 Kubernetes API，负责处理接受请求的工作。API 服务器是 Kubernetes 控制平面的前端。
- kube-apiserver = 集群的 "大门 / 前台"
- 所有操作（kubectl、dashboard、程序调用）都必须走它
- 别人不能直接碰数据库，只能通过 API 服务器
Kubernetes API 服务器的主要实现是 kube-apiserver。kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
- 可以同时开多个 apiserver
- 前面加负载均衡，压力大就多启几个，保证稳定。
三、etcd
一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。
- etcd = 集群的 "账本 / 数据库"
- 存：
- 有哪些节点
- 有哪些 Pod、Deployment
- 期望状态、配置...... 所有集群信息
- 要求：数据一致、不能丢、不能乱
如果你的 Kubernetes 集群使用 etcd 作为其后台数据库，请确保你针对这些数据有一份备份计划。
- etccd 挂了 / 数据丢了 = 集群废了
- 生产必须备份 etcd
四、kube-scheduler
kube-scheduler 是控制平面的组件，负责监视新创建的、未指定运行节点的 Pod，并选择节点来让 Pod 在上面运行。
- kube-scheduler = "调度员 / 派单员"
- 新来一个 Pod，还没说放哪台机器
- scheduler 负责选一台最合适的节点
调度决策考虑的因素包括单个 Pod 及多个 Pod 集合的资源需求、软硬件及策略约束、亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
- 选机器时会看：
- 内存 / CPU 够不够
- 能不能同节点放多个 Pod
- 是不是要靠近某个存储
- 是不是不能和某些 Pod 放一起......
五、kube-controller-manager
kube-controller-manager 是控制平面的组件，负责运行控制器进程。
- controller-manager = 一堆 "自动管理员" 的集合
- 内部有很多小控制器，各自管一类事
从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
- 逻辑上是多个小工具
- 实际打包成一个程序一起跑，方便管理
控制器有许多不同类型。以下是一些例子：
- Node 控制器：负责在节点挂掉时处理
- Job 控制器：管一次性任务
- EndpointSlice 控制器：把 Service 和 Pod 连起来
- ServiceAccount 控制器：自动创建默认账号
简单理解：每个控制器都在死循环：
- 看 "期望状态"
- 看 "实际状态"
- 不一样就动手改
六、cloud-controller-manager
一个 Kubernetes 控制平面组件，嵌入了特定于云平台的控制逻辑。
- 云厂商专用的控制器
- 比如阿里云、腾讯云、AWS 自己的逻辑
云控制器管理器允许将你的集群连接到云提供商的 API 之上，并将与云平台交互的组件同与你的集群交互的组件分离开来。
- 让 K8s 可以调用云厂商的功能：
- 云服务器
- 云负载均衡
- 云硬盘等
cloud-controller-manager 仅运行特定于云平台的控制器。因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，所部署的集群不包含云控制器管理器。
- 自己玩的集群（虚拟机 / 本地）一般没有这个组件
- 只有云上托管的 K8s 才有
第二部分：节点组件（每台机器都有的）
七、kubelet
kubelet 会在集群中每个节点（node）上运行。它保证容器（containers）都运行在 Pod 中。
- kubelet = 每台节点的 "现场代理"
- 接收来自控制平面的指令
- 负责：
- 启动 / 停止 Pod
- 检查 Pod 健康
- 向大脑汇报本机状态
kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
- 只管 K8s 下发的 Pod
- 你手动 docker run 的容器，它不管
八、kube-proxy（可选）
kube-proxy 是集群中每个节点（node）上所运行的网络代理，实现 Kubernetes 服务（Service）概念的一部分。
- kube-proxy = 节点上的 "网络管家"
- 负责实现 Service 的访问规则
kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
- 比如：
- 访问
Service IP→ 转发到背后的 Pod - 保证每个节点都有一样的网络规则
- 访问
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。否则，kube-proxy 仅做流量转发。
- 一般用 iptables/ipvs 做转发规则
如果你使用网络插件为 Service 实现本身的数据包转发，并提供与 kube-proxy 等效的行为，那么你不需要在集群中的节点上运行 kube-proxy。
- 有些高级网络插件（如 Cilium）可以替代 kube-proxy
九、容器运行时
这个基础组件使 Kubernetes 能够有效运行容器。它负责管理 Kubernetes 环境中容器的执行和生命周期。
- 容器运行时 = 真正跑容器的软件
- K8s 本身不直接跑容器，交给它
Kubernetes 支持许多容器运行环境，例如 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
- 现在主流：containerd
- 以前常用 Docker，现在也大多走 containerd
第三部分：插件（Addons）
十、DNS
尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS，因为很多示例都需要 DNS 服务。
- 集群内部 DNS 服务器
- 标配，几乎必装
集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
- 比如
my-service.default.svc.cluster.local能解析到对应 IP
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
- 容器里直接用 Service 名字就能访问
十一、Web 界面（仪表盘）
Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身，并进行故障排除。
- K8s 官方网页控制台
- 可以网页上看 Pod、Deployment、日志等
十二、容器资源监控
容器资源监控将关于容器的一些常见的时序度量值保存到一个集中的数据库中，并提供浏览这些数据的界面。
- 收集：CPU、内存、网络、磁盘等指标
- 常见组合：Prometheus + Grafana
十三、集群层面日志
集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中，这种集中日志存储提供搜索和浏览接口。
- 把所有容器日志收到一起
- 方便搜索、排查问题
十四、网络插件
网络插件是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信。
- CNI 插件 = 集群网络的 "底层组网工具"
- 负责：
- 给 Pod 发 IP
- 让不同节点的 Pod 能互相通信
- 常见：Calico、Flannel
第四部分：架构变种
十五、控制平面部署方式
传统部署：直接装在机器上，用 systemd 管理
- 比较老的方式，直接装系统服务
静态 Pod：由 kubelet 管理控制平面，kubeadm 常用
- 现在kubeadm 装集群常用这种
- 控制平面组件也以 Pod 形式运行，但由 kubelet 直接管理
自托管：控制平面本身也在 K8s 里以普通 Pod 运行
- 更高级：大脑自己也在集群里跑
托管 Kubernetes 服务：云厂商帮你管控制平面
- 比如阿里云 ACK、腾讯云 TKE
- 你不用管大脑，只管业务
十六、工作负载调度说明
小 / 开发集群：控制平面和业务可以混跑
- 学习用：一台机器既是大脑又是工作节点
生产大集群：专门节点跑控制平面，和业务隔离
- 保证大脑稳定，不被业务影响
十七、集群管理工具
像 kubeadm、kops 和 Kubespray 这样的工具提供了不同的集群部署和管理方法
- kubeadm：官方推荐，适合自己搭建集群
- kops、Kubespray：更自动化、大规模部署工具
极简总结（一句话版）
- 控制平面 ：大脑，管全局、调度、自动修复
- apiserver：大门
- etcd：数据库
- scheduler：派单
- controller-manager：一堆自动管理员
- 节点组件 ：每台机器都有
- kubelet：现场代理
- kube-proxy：网络规则
- 容器运行时：真正跑容器
- 插件 ：增强功能
- DNS、Dashboard、监控、日志、CNI 网络
┌─────────────────────────────────────────────────────────┐ │ 【控制平面（大脑）】 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌───────────┐ │ │ │ kube-apiserver │←──→│ etcd │←──→│ 调度器 │ │ │ │ （唯一入口） │ │ （集群账本） │ │kube-scheduler│ │ │ └─────────────┘ └─────────────┘ └───────────┘ │ │ ↑ ↑ │ │ │ │ │ │ ↓ ↓ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │控制器管理器 │ │云控制器管理器 │ │ │ │kube-controller- │ │cloud-controller-│ │ │ │manager（自动修复）│ │manager（云厂商）│ │ │ └─────────────────┘ └─────────────────┘ │ └─────────────────────────────────────────────────────────┘ ↑ │ 下发指令、同步状态 ↓ ┌─────────────────────────────────────────────────────────┐ │ 【工作节点（工人）】 │ │ ┌─────────┐ ┌─────────┐ ┌─────────────────────┐ │ │ │ kubelet │←─│kube-proxy│──│ 容器运行时 │ │ │ │（节点代理）│ │（网络规则）│ │（containerd等） │ │ │ └─────────┘ └─────────┘ └─────────────────────┘ │ │ ↑ │ │ │ │ │ ┌─────────────┐ │ │ │ Pod │ │ │ │（业务容器） │ │ │ └─────────────┘ │ └─────────────────────────────────────────────────────────┘ ↑ │ ┌─────────────────────────────────────────────────────────┐ │ 【插件（增强）】 │ │ CNI网络(Calico/Flannel) 集群DNS Dashboard 监控日志 │ └─────────────────────────────────────────────────────────┘