Kubernetes (K8s) 是一个典型的分布式系统，采用主从架构（Master-Worker Architecture）。一个 K8s 集群主要由两部分组成：

1. 控制平面 (Control Plane / Master Node)：集群的“大脑”，负责管理和决策。
2. 工作节点 (Worker Node)：集群的“四肢”，负责实际运行容器应用。

以下是详细的组件架构及其作用解析：

---

一、 控制平面 (Control Plane / Master Node)

控制平面负责维护集群的全局状态，管理集群的生命周期。它通常运行在 Master 节点上。

1. kube-apiserver (API 服务器)

• 角色：集群的统一入口和前端接口。
• 作用：
  • 所有的组件（无论是用户通过 kubectl，还是 Worker 节点，或者是 Master 内部组件）都必须通过 API Server 进行通信。
  • 负责接收请求，进行认证（Authentication）、授权（Authorization）和准入控制（Admission Control）。
  • 它是唯一能直接与 etcd 数据库交互的组件。

2. etcd (存储后端)

• 角色：集群的数据库。
• 作用：
  • 一个高可用的键值对（Key-Value）存储系统。
  • 存储集群的所有配置数据和状态信息（例如：有哪些 Node，运行了哪些 Pod，期望状态是什么）。
  • 注意：etcd 是 Kubernetes 中最关键的数据源，必须定期备份。

3. kube-scheduler (调度器)

• 角色：资源的分配者。
• 作用：
  • 负责监听新创建的 Pod（尚未分配节点）。
  • 根据算法（资源需求、亲和性规则、节点负载等）选择一个最合适的 Worker Node 来运行这个 Pod。
  • 它只负责“决定”去哪里，不负责“执行”启动。

4. kube-controller-manager (控制器管理器)

• 角色：集群的管家/调节器。
• 作用：
  • 运行一系列后台进程（控制器），负责监控集群的当前状态，并确保它与期望状态（Desired State） 保持一致。
  • 常见的控制器包括：
    • Node Controller：节点宕机时采取行动。
    • Replication Controller：确保 Pod 的副本数量正确。
    • Endpoint Controller：管理 Service 和 Pod 之间的关联。

5. cloud-controller-manager (云控制器管理器 - 可选)

• 作用：如果 K8s 运行在公有云（如 AWS, Azure, 阿里云）上，它负责与云服务商的 API 交互（例如创建云负载均衡器、挂载云硬盘等）。

---

二、 工作节点 (Worker Node)

工作节点是实际运行业务应用的地方。每个 Worker 节点上都运行着以下组件：

1. kubelet

• 角色：节点的代理人/船长。
• 作用：
  • 它是运行在每个节点上的主要“代理”。
  • 它接收来自 API Server 的指令（例如：“在这个节点启动一个 Pod”）。
  • 它管理该节点上 Pod 的生命周期（启动、停止、监控健康状态）。
  • 它定期向 Master 汇报节点自身的资源使用情况和健康状态。

2. kube-proxy

• 角色：网络代理/交警。
• 作用：
  • 维护节点上的网络规则（通常通过 iptables 或 IPVS 实现）。
  • 负责实现 Kubernetes Service 的概念，确保流量能够正确地负载均衡并转发到后端的 Pod。
  • 让集群内部或外部的网络请求能找到对应的 Pod。

3. Container Runtime (容器运行时)

• 角色：实际的执行引擎。
• 作用：
  • 负责真正地下载镜像、解压镜像并运行容器。
  • Kubernetes 支持多种运行时，最常见的是 containerd、CRI-O，早期版本常用 Docker。

---

三、 形象的比喻（餐厅模型）

为了方便记忆，可以将 Kubernetes 集群比作一个大型餐厅：

• Master Node (管理层):

  • API Server: 前台/服务员。所有顾客（用户）点菜都找他，后厨（Worker）有问题也汇报给他。
  • etcd: 订单记录本/菜单。记录了所有桌子的状态和点的菜。
  • Scheduler: 领班。看到新订单，决定派给哪个厨师（Node）去做（根据厨师忙闲程度）。
  • Controller Manager: 经理。巡视厨房，如果发现某个菜做坏了（Pod 挂了），立马安排重做。

• Worker Node (后厨):

  • Kubelet: 厨师长。负责管理自己灶台（Node）上的所有任务，听从领班指挥，确保菜（Pod）做好了。
  • Container Runtime: 炉灶/锅具。实际把菜（容器）煮熟的地方。
  • Kube-proxy: 传菜员。确保做好的菜能准确送到对应的桌号（网络转发）。

四、 总结图解流程

当你在 Kubernetes 中部署一个应用时（例如 kubectl run nginx）：

1. kubectl 发送请求给 API Server。
2. API Server 将请求写入 etcd。
3. Scheduler 发现有一个新 Pod 没地方去，计算后决定把它放在 Node-A，并告诉 API Server。
4. Node-A 上的 Kubelet 监听到 API Server 的指令（属于我的任务来了）。
5. Kubelet 指挥 Container Runtime 拉取 Nginx 镜像并启动容器。
6. Kube-proxy 为这个 Nginx 配置网络规则，使其可以被访问。
7. Controller Manager 持续监控，如果 Nginx 挂了，它会请求创建一个新的。