闯进 Kubernetes 的世界（三）

第三章：Kubernetes(K8s) 如何运转：深入其工作机制

在第二章中，我们认识了 K8s 世界里的主要“角色”：主节点、工作节点、Pod、Deployment 和 Service。

现在，我们将把这些角色串联起来，揭示 K8s 这个“智能机器人”是如何通过巧妙的协作机制，让你的应用程序在集群中高效、稳定地运行的。

3.1 K8s 基本架构概览

在先前的章节中我们得知，K8s 集群从逻辑上可以划分为两个主要部分：控制平面 (Control Plane) 和 工作节点 (Worker Nodes)。它们通过网络相互通信，共同完成任务。

+-----------------------------+          +-----------------------------+
|   控制平面 (Control Plane)   |          |     工作节点 (Worker Node)    |
|                             |          |                             |
|  +---------------------+    |          |   +---------------------+   |
|  |     API Server      |<------------------|       Kubelet       |   |
|  +----------+----------+    | API 调用  |   +----------+----------+   |
|             |               |          |             |               |
|  +----------v----------+    |          |  +----------v----------+    |
|  |        etcd         |    |          |  |     Kube-proxy      |    |
|  +---------------------+    |          |  +---------------------+    |
|                             |          |                             |
|  +---------------------+    |          |  +---------------------+    |
|  |      Scheduler      |    |          |  |  Container Runtime  |    |
|  +---------------------+    |          |  +----------+----------+    |
|                             |          |             |               |
|  +---------------------+    |          |  +----------v----------+    |
|  |  Controller Manager |    |          |  |      Pod(s)         |    |
|  |                     |    |          |  |   (Your Apps)       |    |
|  +---------------------+    |          |  +---------------------+    |
|                             |          |                             |
+-----------------------------+          +-----------------------------+
          ^                                       ^
          |                                       |
          |           集群网络 (Cluster Network)   |
          +---------------------------------------+
          |
          v
     用户/管理员 (kubectl CLI)

控制平面 (Master)： 负责集群的全局决策和管理。它接收用户的指令，维护集群的期望状态。

工作节点 (Worker)： 负责运行实际的应用程序容器。它们接收控制平面的指令并执行。

它们之间通过 Master API Server 和 Worker Kubelet 之间的 API 通信机制来进行调度上的沟通，Master API Server 和 Worker Kubelet 都是负责向其他组件/模块下达内部指令。

3.2 K8s 的启动与运行流程

当你在 K8s 中部署一个应用程序时，背后会发生一系列精密的协作。我们以部署一个新的 Deployment 为例：

用户提交意图 (Desired State)： 你通过 kubectl 命令行工具（或 API）向 K8s 提交一个 Deployment 的配置文件（YAML 文件）。这个文件声明了你希望应用程序运行的副本数量、镜像版本等。

用户 -> kubectl -> API Server (提交 Deployment YAML)

API Server 接收并保存： API Server 接收到这个请求，进行验证，并将其保存在 etcd 中。此时，集群的“期望状态”发生了变化。

API Server -> etcd (保存 Deployment 信息)

Controller Manager 发现变化：Controller Manager 中的 Deployment 控制器持续监控 API Server。它发现 etcd 中的 Deployment 数量与实际运行的 Pod 数量不符。它会计算出需要创建的 Pod 数量，并请求 API Server 创建这些 Pod。

Controller Manager (发现不符) -> API Server (创建 Pod 对象)

Scheduler 调度 Pod：Scheduler 持续监控 API Server，发现有新的 Pod 对象（它们还没有被分配到任何工作节点）。它会根据 Pod 的资源需求、节点负载、亲和性等因素，选择一个最合适的工作节点，并将这个“分配决定”更新回 API Server。

Scheduler (选择节点) -> API Server (更新 Pod 状态，绑定到工作节点) -> Worker Node Kubelet

Kubelet 启动 Pod： 被选中的工作节点上的 Kubelet 持续监控 API Server。它发现有一个 Pod 被调度到自己身上了。Kubelet 随即指示本地的容器运行时 (Container Runtime)（如 Docker）拉取镜像并启动 Pod 中的容器。只有这时候，Pod 才是被真正的创建，在 Master 上的 Pod 只是一个标识，并非实体。

Kubelet (收到调度信息) -> Container Runtime (拉取镜像，启动容器) 

Kubelet 汇报状态： Pod 启动后，Kubelet 会持续监控 Pod 的健康状况，并将 Pod 的实时状态（如运行中、就绪、失败等）汇报给 API Server。

Service 流量转发 (可选)： 如果你的应用程序需要对外提供服务，你还会创建一个 Service。Kube-proxy 会在各个工作节点上配置网络规则，将流向 Service IP 的请求负载均衡地转发到后端健康的 Pod 上。

外部请求 -> Kube-proxy -> 应用程序 Pod

3.3 K8s 内部的调度与通信机制

3.3.1 调度机制：K8s 如何选择“家”？

K8s 的调度器 (Scheduler) 是一个非常智能的“房产中介”。当一个新的 Pod 需要运行时，调度器会经历两个阶段来选择最合适的“家”（工作节点）：

• 预选 (Predicates)： 过滤掉不符合条件的节点。例如，如果一个节点没有足够的内存，或者没有所需的特定硬件（如 GPU），它就会被排除。这就像中介先筛选掉不满足基本要求的房子。
• 优选 (Priorities)： 对剩下的节点进行打分排名。例如，资源利用率较低的节点可能得分更高，或者与 Pod 有亲和性（自定义权重）的节点会得到加分。这就像中介根据你的偏好，给符合条件的房子打分。

在 K8s v1.19 及之后版本中，调度框架（Scheduling Framework）已经成为主流，其对应的阶段术语演变成了 过滤 (Filter) 和 打分 (Score)。

• Filter 插件等同于 Predicates 的功能。
• Score 插件等同于 Priorities 的功能。

最终，得分最高的节点被选中，Pod 就被调度到该节点上。

3.3.2 内部通信：K8s 各组件如何“说话”？

K8s 内部的各个组件之间并非直接“手拉手”通信，它们的核心通信方式是：

• API Server 为核心： 所有的组件都通过 API Server 进行通信。它们不会直接访问 etcd，也不会直接调用其他组件的函数。
• “拉取”而非“推送”： 大多数组件都是通过“拉取”的方式获取信息。例如，Kubelet 会周期性地向 API Server 查询分配给自己的 Pod 列表；Controller Manager 会监听 API Server 的事件流来发现集群状态的变化。
• 状态同步： 组件通过在 etcd 中读写对象（通过 API Server 中转）来同步彼此的状态和信息。这确保了集群状态的最终一致性。

这种设计模式使得 K8s 具有极高的可伸缩性、弹性和解耦性。即使某个组件暂时离线，只要 etcd 中的状态不变，它恢复后依然可以从 API Server 获取最新状态并继续工作，不会影响整个集群的稳定性。

第四章节已更新，请前往账号主页搜索：闯进 Kubernetes 的世界。