别再被专业术语绕晕了：用大白话带你拆解 K8s 的五大核心组件

Kubernetes（K8s）是目前最流行的容器编排系统，但它的专业术语常常让人望而生畏。其实，K8s 就像一家高效运转的自动化工厂。要理解它，我们只需要拆解它的“大脑”和“肌肉”——即控制平面（Control Plane）和工作节点（Worker Node）上的关键角色。

K8s的五大核心组件，是支撑整个集群自动化运行的关键。

K8s的“大脑”：控制平面（Control Plane）

控制平面是集群的指挥中心，它负责做出决策、存储状态和响应用户请求。它主要由以下四个组件构成：

1. API Server：集群的“前台接待”和“安全门”

大白话理解： 它是你与 K8s 交互的唯一入口。无论你想部署应用、查看状态，还是删除服务，所有命令都必须通过它。它负责验证你的身份（认证与授权），并确保所有组件对集群状态的修改都是合法的。

• 核心功能： 暴露 Kubernetes API，处理 REST 请求，是集群所有组件通信的中心枢纽。

2. etcd：集群的“中央数据库”或“记忆”

大白话理解： etcd 就像 K8s 的共享硬盘，或者说是集群的“大脑记忆”。它存储了集群所有配置数据、状态和元信息。重要的是，它存储的是集群的“期望状态”（Desired State）。

• 核心功能： 持久化存储集群状态，保证数据一致性（高可用）。如果 etcd 挂了，K8s 就“失忆”了。

3. Scheduler：集群的“任务分配者”

大白话理解： 当你告诉 K8s 运行一个新的应用（Pod）时，Scheduler 就像一位经验丰富的 HR 经理或物流调度员。它的任务是决定这个新的应用应该运行在哪个“Worker Node”上。

• 核心功能： 监听新创建的、但尚未分配节点（Node）的 Pod，然后根据节点的资源利用率、健康状况、约束条件等，为 Pod 选择一个最佳的运行节点。

4. Controller Manager：集群的“不倦的监督者”

大白话理解： Controller Manager 是一组控制器（Controller）的集合，它们像一群尽职尽责的工头。它们持续不断地将集群的“当前状态”与 etcd 中存储的“期望状态”进行对比。

• 核心功能： 确保实际状态与期望状态一致。例如，如果你期望运行 3 个 Nginx 副本，但其中一个挂了，Controller Manager 就会立即检测到差异，并告诉 API Server 启动一个新的 Pod 来补充，使副本数回到 3。

K8s的“肌肉”：工作节点（Worker Node）

工作节点是真正运行用户应用（容器）的地方。它们由以下核心组件驱动：

5. Kubelet：节点的“驻地代理”和“执行者”

大白话理解： Kubelet 运行在每个工作节点上，是控制平面在本地的“代理”。它不处理调度决策，它只负责执行命令。它会不断向 API Server 汇报自己的节点状态，并接收 API Server 下发的任务（比如运行某个 Pod）。

• 核心功能： 确保 Pod 中描述的容器处于运行状态。它会与容器运行时（如 Docker 或 Containerd）通信来启动、停止和管理容器。

实战演示：一个 Pod 如何被启动？

我们通过一个简单的 Nginx 部署流程来串联这五个组件：

假设我们提交了一个 deployment.yaml 文件，要求运行两个 Nginx 副本。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

1. 用户提交 (kubectl apply -f deployment.yaml)：请求到达 API Server。
2. 记录状态：API Server 验证请求后，将“期望运行 2 个 Nginx”的状态写入 etcd。
3. 监督启动：Controller Manager (Deployment Controller) 发现 etcd 中期望状态是 2，但实际状态是 0，于是它创建了两个新的 Pod 对象，并将它们标记为“尚未调度”。
4. 分配任务：Scheduler 立即发现这两个“尚未调度”的 Pod，通过计算资源，决定将 Pod A 分配给 Node 1，将 Pod B 分配给 Node 2，并将这个决定通过 API Server 写入 etcd。
5. 本地执行：Node 1 上的 Kubelet 持续监听 API Server。当它发现有一个 Pod 任务分配给了自己时，它会立刻通知本地的容器运行时，启动 Nginx 容器。
6. 反馈：Kubelet 启动容器后，持续向 API Server 汇报 Pod 的运行状态（Running）。

通过这个流程，你就看到了 K8s 的五大核心组件是如何协同工作，将一个抽象的部署请求，转化为实际运行的容器的。