---

深入理解 Kubernetes 架构：构建弹性分布式系统的基石

在当今云原生时代，容器化技术已成为应用部署的标准实践。然而，随着容器数量的爆炸式增长以及分布式系统带来的复杂性，如何有效地管理、调度、扩展和维护这些容器成为了新的挑战。Kubernetes（通常简称 K8s）应运而生，作为一个开源的容器编排平台，它极大地简化了这一过程。

要真正掌握 Kubernetes 并发挥其强大能力，理解其底层架构至关重要。Kubernetes 的设计精妙且高度模块化，这种架构不仅保证了其灵活性和可扩展性，也为其带来了强大的自愈能力和自动化特性。本文将深入剖析 Kubernetes 的核心架构，详细介绍其各个关键组件及其协同工作方式。

1. Kubernetes 的核心理念与高层架构

在深入细节之前，先理解 Kubernetes 的核心理念：声明式配置（Declarative Configuration）和自动化（Automation）。用户通过 YAML 或 JSON 文件描述他们期望的系统状态（例如，某个应用需要运行多少个副本），Kubernetes 的各个组件会不断地工作，将当前的实际状态调整到与期望状态一致。这种“所见即所得”的方式极大地简化了运维。

从高层来看，一个 Kubernetes 集群主要由两大部分组成：

• 控制平面（Control Plane / Master Nodes）： 这是 Kubernetes 集群的“大脑”，负责管理集群的状态、调度工作负载、响应用户请求等。控制平面通常由多个高可用的组件构成，运行在专用的节点上（传统上称为 Master 节点，现在更倾向于称为控制平面节点）。
• 工作节点（Worker Nodes）： 这是 Kubernetes 集群的“工人”，负责运行实际的用户应用程序（以 Pods 的形式）。每个工作节点都包含必要的组件，使其能够接收控制平面发来的指令，并管理其上的 Pods。

这两部分通过网络相互通信，共同协作来维护整个集群的稳定运行和用户定义的工作负载。

2. 控制平面（Control Plane）核心组件详解

控制平面是 Kubernetes 的指挥中心，它的稳定性和可靠性对整个集群至关重要。控制平面由一系列相互协作的组件组成，这些组件通常以进程的形式运行。

2.1 API Server (kube-apiserver)

API Server 是 Kubernetes 控制平面的核心，也是所有外部和内部通信的唯一入口。它是整个集群的“前门”。

• 核心功能：

  • 对外接口： 提供 Kubernetes API，用户、kubectl 命令行工具、以及其他集群组件都通过这个 API 与集群交互。它是 RESTful API，可以通过 HTTP/HTTPS 访问。
  • 身份验证和授权： 对所有请求进行身份验证（Authentication）和授权（Authorization），确保只有合法的用户或组件才能执行允许的操作。通常结合 RBAC（Role-Based Access Control）模型。
  • 数据校验和准入控制： 在将数据写入后端存储（etcd）之前，对请求的数据进行格式、逻辑上的校验。准入控制器（Admission Controllers）可以在对象创建、修改、删除等阶段拦截请求，执行额外的策略（例如，限制资源使用、注入 Sidecar 容器等）。
  • 状态存储的唯一接口： API Server 是唯一能直接与集群状态存储（etcd）交互的组件。所有对集群状态的读取和修改都必须通过 API Server。这保证了状态的一致性。
  • Watch 机制： API Server 支持“Watch”机制，允许其他组件（如 Controller Manager, Scheduler, Kubelet）订阅特定资源的变化。当资源发生变化时，API Server 会主动通知这些订阅者，而不是让它们不断轮询，这大大提高了系统的效率和响应速度。

• 重要性： API Server 是整个集群的枢纽。它的高可用性是集群高可用的前提。通常在生产环境中，API Server 会以多个副本的形式运行，并通过负载均衡器对外提供服务。

2.2 etcd

etcd 是一个分布式、一致性的键值存储系统，它是 Kubernetes 集群的“大脑的记忆”。etcd 存储了整个集群的所有配置数据和状态信息，包括 Pods、Services、Deployments、ConfigMaps、Secrets、节点信息、网络信息等。

• 核心功能：

  • 集群状态的单一真相来源（Single Source of Truth）： 所有 Kubernetes 对象的状态都保存在 etcd 中。其他控制平面组件和工作节点上的 Kubelet 都通过 API Server 读取或监听 etcd 中的状态变化。
  • 高可用和强一致性： etcd 通常以集群模式运行，采用 Raft 一致性算法，保证了数据的强一致性和高可用性。即使部分 etcd 节点失效，整个 etcd 集群仍然能够提供服务。
  • Watch 机制支持： etcd 原生支持 Watch 机制，这使得 API Server 能够高效地感知状态变化并通知其他组件。

• 重要性： etcd 的性能和稳定性直接影响到整个 Kubernetes 集群的性能和可靠性。如果 etcd 集群出现问题，Kubernetes 将无法得知集群的当前状态和期望状态，整个集群会陷入瘫痪。因此，etcd 的备份和恢复策略至关重要。

2.3 Controller Manager (kube-controller-manager)

Controller Manager 是 Kubernetes 的“大脑的执行者”，它包含了一系列控制器（Controllers）。每个控制器都负责一种特定的资源类型，它们的工作是持续监听 API Server，比较集群的当前状态（Actual State）与用户期望的状态（Desired State，存储在 etcd 中），并采取行动将实际状态调整到与期望状态一致。

Controller Manager 通常运行在一个单独的进程中，但它内部管理着多个逻辑上独立的控制器，例如：

• 节点控制器（Node Controller）： 负责监听节点的状态。当节点宕机时，节点控制器会发现这一变化（通过节点发送心跳或 API Server 的超时机制），并将该节点标记为不健康。如果该节点上运行了由 StatefulSet 或 DaemonSet 管理的 Pods，节点控制器还会负责回收这些 Pods 的资源或在其他健康节点上重新创建。
• 副本控制器（Replication Controller / ReplicaSet Controller）： ReplicaSet 是 Replication Controller 的后继者，负责确保某个 Pod 模板始终保持指定数量的副本在运行。如果副本数量少于期望值，它会创建新的 Pods；如果多于期望值，它会删除多余的 Pods。Deployment Controller 内部使用 ReplicaSet Controller。
• 端点控制器（Endpoints Controller）： 负责填充 Endpoints 对象。Endpoints 对象存储了某个 Service 后面对应的 Pod IP 地址和端口信息。当 Pods 发生变化（创建、删除、IP 地址变化）时，Endpoints Controller 会更新对应的 Endpoints 对象，供 Kube-proxy 和 CoreDNS 等组件使用。

• 服务账号和令牌控制器（Service Account & Token Controller）： 负责为新的 Namespace 创建默认的 ServiceAccount，并为 ServiceAccount 创建对应的 Secret，包含访问 API Server 的 Token。

• 重要性： Controller Manager 是实现 Kubernetes 自动化和自愈能力的关键。通过这些控制器，Kubernetes 能够持续监控集群，并在出现偏差时自动进行修正，确保系统按照用户的期望运行。

2.4 Scheduler (kube-scheduler)

Scheduler 是 Kubernetes 的“大脑的调度员”，负责决定新创建的 Pods 应该运行在哪个工作节点上。

• 核心功能：

  • 监听新 Pods： Scheduler 持续监听 API Server，寻找那些尚未被分配到节点的 Pods。
  • 节点过滤（Filtering）： 根据 Pod 的资源需求（CPU、内存）、节点上的资源可用性、节点的亲和性/反亲和性规则、污点/容忍度（Taints/Tolerations）、Pod 的 Node Selector 等条件，过滤掉不符合要求的节点，得到一个可行的节点列表。
  • 节点评分（Scoring）： 对过滤后的可行节点进行评分，评估每个节点的适合程度。评分因素可能包括节点的资源使用率、Pod 间的亲和性/反亲和性、节点上的 Pod 数量等。不同的策略和算法可以影响评分结果。
  • 节点选择： 选择得分最高的节点作为 Pod 的目标运行节点。
  • 绑定 Pod 到节点： 将 Pod 的信息（包括选择的节点名称）通过 API Server 更新到 etcd 中。这个过程称为“绑定”（Binding）。

• 重要性： Scheduler 的效率和策略直接影响到资源的利用率、应用的性能以及集群的均衡性。一个好的调度器能够确保工作负载合理地分布在集群中，避免某些节点过载而其他节点空闲。

2.5 Cloud Controller Manager (cloud-controller-manager)

Cloud Controller Manager 是一个可选的组件，它仅在 Kubernetes 运行在公有云（如 AWS, GCP, Azure）或某些私有云环境中时才有用。它的作用是将云平台的特定 API 集成到 Kubernetes 中。

• 核心功能：

  • 节点管理： 当云平台的 VM 被删除时，Cloud Controller Manager 可以通知 Kubernetes 将对应的 Node 对象删除。
  • 路由管理： 配置云平台的网络路由，以供 Pod 通信。
  • 服务管理： 创建、更新和删除云平台的负载均衡器（Load Balancer），用于实现 Service 的 Type=LoadBalancer。
  • 卷管理： 与云平台的存储服务集成，创建、挂载和卸载持久卷（Persistent Volumes）。

• 重要性： 它使得 Kubernetes 能够利用云平台的基础设施能力，为用户提供更丰富的服务类型和更紧密的集成。在自建数据中心部署 Kubernetes 时，通常不需要这个组件。

3. 工作节点（Worker Nodes）核心组件详解

工作节点是 Kubernetes 集群中执行实际任务的机器。每个工作节点上都运行着接收控制平面指令并管理其上 Pods 的组件。

3.1 Kubelet

Kubelet 是运行在每个工作节点上的代理程序。它是节点上的“管家”。

• 核心功能：

  • 向 API Server 注册节点： 当 Kubelet 启动时，它会向 API Server 注册自己所在的节点信息。
  • 监听分配给本节点的 Pods： Kubelet 通过 Watch 机制监听 API Server，获取所有分配给本节点的 Pods 信息（这些 Pods 由 Scheduler 绑定到该节点）。
  • Pod 生命周期管理： Kubelet 负责下载 Pod 描述文件（如果来自文件或 HTTP 端点），通过容器运行时（Container Runtime）创建、启动、停止和删除 Pod 中的容器。
  • 容器健康检查： 执行 Pods 中定义的 Liveness 和 Readiness 探针，并将结果报告给控制平面。如果容器不健康，Kubelet 会根据 Pod 的重启策略进行处理。
  • 节点状态报告： 向 API Server 报告节点的状态（如资源使用、健康状况、已运行的 Pods 列表）。
  • 容器资源监控： 与 cAdvisor（或者集成到容器运行时中的监控功能）协作，收集节点和容器的资源使用情况，报告给控制平面（通过 Metric Server 等组件）。
  • 卷管理： 负责挂载和卸载 Pod 使用的卷（Volumes）。

• 重要性： Kubelet 是工作节点上的核心组件，它直接负责 Pod 的运行和管理。没有 Kubelet，工作节点就无法接收控制平面发来的指令，也无法执行工作负载。

3.2 Kube-proxy

Kube-proxy 是运行在每个工作节点上的网络代理或服务发现代理。它是节点上的“交通管理员”。

• 核心功能：

  • 实现 Service 抽象： Kube-proxy 监听 API Server，获取 Services 和 Endpoints 对象的变化。
  • 维护网络规则： 根据 Services 和 Endpoints 信息，Kube-proxy 在节点上维护网络规则（通常使用 iptables 或 IPVS）。这些规则使得用户可以通过 Service 的固定 IP 和端口访问后端 Pods，而无需关心 Pod 的具体 IP 地址和节点位置。Kube-proxy 会将 Service 的流量负载均衡到其背后的健康 Pods 上。
  • 服务发现： Kube-proxy 使得 Service 具有稳定的网络身份，隐藏了后端 Pods 的动态性，实现了服务发现的功能。

• 工作模式（常见模式）：

  • iptables 模式： Kube-proxy 使用 iptables 规则来捕获 Service 的流量，并通过 DNAT（目标网络地址转换）将其转发到后端 Pods。这是默认也是最常用的模式。
  • IPVS 模式： 使用 Linux 内核中的 IP Virtual Server 功能。IPVS 模式通常在处理大量 Service 时性能更好。
  • Userspace 模式： 较老的模式，性能较差，已不常用。
  • Kernelspace 模式： 结合了 iptables 和 IPVS 的优点。

• 重要性： Kube-proxy 使得 Kubernetes 的 Service 抽象成为可能。它解决了 Pods 的动态性和不稳定性带来的网络访问问题，为应用提供了稳定的网络入口。

3.3 容器运行时（Container Runtime）

容器运行时是运行在每个工作节点上的软件，负责拉取容器镜像、解压、创建和运行容器。它是节点上的“集装箱操作员”。

• 核心功能：

  • 镜像管理： 拉取、管理和存储容器镜像。
  • 容器生命周期： 创建、启动、停止、删除容器。
  • 容器资源隔离： 利用 Linux 内核特性（如 Cgroups, Namespaces）为容器提供资源隔离。
  • 通过 CRI 与 Kubelet 交互： Kubernetes 定义了容器运行时接口（Container Runtime Interface, CRI）。Kubelet 通过 CRI 与兼容的容器运行时进行交互，而不是直接调用具体的容器运行时 API。这使得 Kubernetes 可以支持多种不同的容器运行时。

• 常见容器运行时：

  • Docker Engine： 虽然 Docker 是容器技术的开创者，但 Kubelet 不再直接支持 Docker Engine API。而是通过一个 shim（如 dockershim，目前已被移除）或 CRI 兼容的运行时（如 containerd）来与 Docker 交互。
  • containerd： 一个工业级标准的容器运行时，由 Docker 开源，是 CNCF 的项目。它实现了 CRI，被广泛使用。
  • CRI-O： 一个专门为 Kubernetes 设计的容器运行时，专注于实现 CRI，提供轻量级的选择。
  • Podman, gVisor, Kata Containers 等：其他实现了 CRI 的容器运行时。

• 重要性： 容器运行时是 Kubernetes 能够真正运行容器的基础。CRI 的引入增强了 Kubernetes 的灵活性和互操作性，使得用户可以选择适合自己需求的容器运行时。

4. Kubernetes 的核心对象/概念

除了上述的架构组件，理解 Kubernetes 的核心对象模型也非常关键。用户通过这些对象来描述和管理他们的应用。

• Pod： Kubernetes 中最小的可部署计算单元。一个 Pod 包含一个或多个紧密相关的容器，这些容器共享网络命名空间、存储卷等资源。Pods 是短暂的，通常由更高层级的控制器管理。
• Service： 一种抽象，定义了访问 Pods 集合的策略。它提供了一个稳定的网络入口（IP 地址和端口），并将请求负载均衡到后端的 Pods。Service 的选择器（Selector）通过标签（Labels）匹配 Pods。
• Volume： Pod 中容器可访问的存储目录。Volume 的生命周期独立于 Pod 中的容器，用于实现数据持久化或在容器间共享数据。Kubernetes 支持多种 Volume 类型。
• Namespace： 用于在同一集群中进行逻辑隔离，将集群资源划分为不同的虚拟集群。常用于多租户或划分开发、测试、生产环境。
• Deployment： 提供了一种声明式的方式来管理 Pods 和 ReplicaSets。它可以用于无状态应用的部署、更新、回滚和扩缩容。
• ReplicaSet： 确保在任何时候都有指定数量的 Pod 副本在运行。Deployment 通过管理 ReplicaSet 来实现滚动更新和回滚等功能。
• StatefulSet： 用于管理有状态应用的工作负载。它为 Pods 提供稳定的网络标识和持久存储。
• DaemonSet： 确保在集群中的部分或所有节点上运行 Pod 的一个副本。常用于运行日志收集、监控代理等节点级别的服务。
• Job： 用于运行一次性或批量任务，当任务成功完成时，Job 就会停止。
• CronJob： 用于按照指定的时间表运行 Job。
• ConfigMap 和 Secret： 用于将配置数据和敏感信息（如密码、API 密钥）从应用代码中解耦出来，以便于管理和分发给 Pods。

5. 组件之间的协同工作流程示例

理解了各个组件的功能后，我们来看一个简单的例子：用户如何创建一个 Deployment 来运行一个 Nginx 应用，以及 Kubernetes 如何处理这个请求。

1. 用户提交请求： 用户使用 kubectl apply -f nginx-deployment.yaml 命令提交一个 Deployment YAML 文件。
2. API Server 接收并处理请求：
   • kubectl 将请求发送到 Kubernetes API Server。
   • API Server 对请求进行身份验证和授权检查。
   • API Server 通过准入控制器校验 Deployment 对象。
   • 如果一切正常，API Server 将 Deployment 对象的状态信息写入 etcd。
   • API Server 同时通知所有 Watching Deployment 资源的组件发生了变化。
3. Controller Manager (Deployment Controller) 响应：
   • Deployment Controller 监听到新的 Deployment 对象被创建。
   • 它根据 Deployment 的定义（期望的副本数、Pod 模板等）创建或更新一个对应的 ReplicaSet 对象。并将 ReplicaSet 对象写入 etcd（通过 API Server）。
   • API Server 通知 Watchers ReplicaSet 资源发生变化。
4. Controller Manager (ReplicaSet Controller) 响应：
   • ReplicaSet Controller 监听到新的 ReplicaSet 对象被创建，或者现有的 ReplicaSet 副本数与期望值不符。
   • 它发现需要创建新的 Pods 来达到期望的副本数。
   • ReplicaSet Controller 根据 ReplicaSet 的 Pod 模板创建多个 Pod 对象，并将这些 Pod 对象写入 etcd（通过 API Server）。这些 Pod 对象此时处于“待调度”（Pending）状态，并且没有被分配到任何节点。
   • API Server 通知 Watchers Pod 资源发生变化。
5. Scheduler 响应：
   • Scheduler 监听到新的、未分配节点的 Pods 出现。
   • 对于每个待调度的 Pod，Scheduler 执行过滤和评分算法，选择一个最合适的节点。
   • Scheduler 将选定的节点名称通过 API Server 绑定到 Pod 对象上（更新 etcd）。此时 Pod 对象的状态变为“已绑定”（Bound），并包含节点名称。
   • API Server 通知 Watchers Pod 资源状态发生变化（尤其是节点名称字段）。
6. Kubelet 响应：
   • 节点上的 Kubelet 监听到有 Pod 被绑定到它所在的节点。
   • Kubelet 从 API Server 获取该 Pod 的详细信息。
   • Kubelet 指示该节点上的容器运行时（如 containerd）拉取所需的容器镜像（如 Nginx 镜像）。
   • Kubelet 通过容器运行时创建并启动 Pod 中定义的容器。
   • Kubelet 持续监控 Pod 的健康状况（通过探针）和状态，并将这些信息通过 API Server 报告给控制平面。
7. Kube-proxy 响应（如果同时创建了 Service）：
   • 如果用户还创建了一个 Service 对象来暴露 Nginx Pods。
   • Kube-proxy 监听到新的 Service 和其对应的 Pods (Endpoints) 出现。
   • Kube-proxy 在节点上更新 iptables 或 IPVS 规则，将流向该 Service ClusterIP 的流量转发到后端的 Nginx Pods IP 地址上。
8. 最终状态： 此时，Nginx Pods 已经在工作节点上运行起来，并且可以通过 Service 进行访问。Controller Manager 和 Kubelet 会持续监控状态，如果 Pods 崩溃或节点宕机，相应的控制器会采取行动（如 ReplicaSet Controller 创建新的 Pod，Node Controller 标记节点不健康等），将集群恢复到期望的状态。

这个流程展示了 Kubernetes 各个组件如何协同工作，通过 Watch 机制和声明式 API 实现了复杂的分布式系统的自动化管理。

6. 架构的优点

理解 Kubernetes 的架构，也就理解了其强大的优势：

• 高可用和弹性： 控制平面组件（特に etcd 和 API Server）通常部署为多副本，提供高可用。工作节点可以随时加入或离开集群，Pods 可以在节点间重新调度。控制器自动处理故障。
• 可扩展性： 控制平面和工作节点都可以水平扩展，以处理更大规模的工作负载。CRI、CNI（容器网络接口）、CSI（容器存储接口）等接口的设计，允许集成不同的第三方实现。
• 自愈能力： 控制器不断监控集群状态，并在 Pod、容器、节点等出现故障时自动进行恢复（例如，重启容器、重新调度 Pod）。
• 声明式 API： 用户只需声明期望的状态，Kubernetes 会负责实现它，大大降低了管理复杂性。
• 模块化和插件化： 各个组件相对独立，通过 API 交互，这使得 Kubernetes 易于理解、维护和扩展。各种功能（如调度策略、准入控制器、存储卷插件、网络插件）都可以通过插件方式集成。
• 强大的社区支持和生态系统： 作为 CNCF 的旗舰项目，Kubernetes 拥有庞大的开发者社区和丰富的周边工具。

7. 总结

Kubernetes 的架构设计是其成功的关键。通过清晰地划分控制平面和工作节点的职责，以及控制平面内部各组件（API Server, etcd, Controller Manager, Scheduler）的紧密协作，Kubernetes 构建了一个高度弹性、可扩展和自愈的容器编排系统。

• API Server 作为核心枢纽，处理所有交互并确保状态一致性。
• etcd 作为单一真相来源，存储着整个集群的脉络。
• Controller Manager 及其内部的各种控制器是自动化和自愈能力的基石，它们不断驱动实际状态趋向期望状态。
• Scheduler 负责高效地将工作负载分配到合适的节点。
• 工作节点上的 Kubelet 是实际的执行者，负责管理节点上的 Pods 生命周期。
• Kube-proxy 解决了服务发现和负载均衡的网络问题。
• 容器运行时是运行容器的基础设施。

深入理解 Kubernetes 的架构，不仅能帮助我们更好地使用和管理集群，也能在遇到问题时更快速地定位和解决。这套强大的架构体系是构建现代化、云原生应用的坚实基础。随着 Kubernetes 的不断发展，其架构也在持续演进，但核心的设计理念和组件职责依然是理解这个复杂系统的起点。

---