Kubernetes (k8s) 架构：组件与工作原理 – wiki基地

深入剖析 Kubernetes (k8s) 架构：组件与工作原理

在当今云原生和容器化技术盛行的时代，Kubernetes (简称 K8s) 已经成为容器编排和管理的实际标准。它是一个开源平台，旨在自动化部署、扩展和管理容器化应用程序。理解 Kubernetes 的强大之处，首先需要深入剖析其精巧而稳健的架构。Kubernetes 的设计思想是构建一个分布式系统，通过声明式 API 实现对集群状态的管理，并持续地将当前状态调整到期望状态。

本文将详细介绍 Kubernetes 的核心架构，包括其主要组件以及这些组件如何协同工作，从而实现高效、可靠的容器化应用管理。

Kubernetes 架构概览：控制平面与工作节点

Kubernetes 遵循主/从（Master/Worker）或更准确地说，控制平面/工作节点（Control Plane/Worker Node）的架构模式。整个集群由以下两类主要节点组成：

控制平面 (Control Plane / Master Node): 这是集群的大脑，负责维护集群的整体状态、做出全局决策（如 Pod 调度）、响应事件以及协调各种组件。通常，为了高可用性，控制平面由多个节点组成。
工作节点 (Worker Node / Minion): 这些节点是运行实际容器化应用程序的地方。它们接收来自控制平面的指令，根据这些指令运行 Pods（Kubernetes 中最小的可部署计算单元），并报告其状态。

理解 Kubernetes 的核心在于理解控制平面中的各个组件及其如何与工作节点上的组件交互。

控制平面组件 (Control Plane Components)

控制平面是 Kubernetes 集群的核心，它管理集群的状态并对用户、其他组件和外部交互做出响应。控制平面组件可以运行在单个节点上，或者为了高可用性分散部署在多个节点上。主要组件包括：

1. Kube-APIServer (API 服务器)

角色: API 服务器是 Kubernetes 控制平面的核心，是所有组件（包括外部用户通过 kubectl 命令）与集群进行通信的唯一入口。它是整个系统的“前门”和“中枢”。
工作原理:
- API 接口: 它提供一个 RESTful API，允许用户和内部组件以声明式的方式与 Kubernetes 对象（如 Pod、Service、Deployment 等）进行交互。所有的操作，无论是创建、读取、更新还是删除，都通过 API 服务器进行。
- 认证、授权和准入控制: API 服务器在处理任何请求之前，会首先进行客户端认证（Authentication）、用户或组件是否具有执行请求操作的权限授权（Authorization），以及是否符合集群策略的准入控制（Admission Control）。这是集群安全的第一道防线。
- 状态持久化: API 服务器负责将集群的状态持久化到其后端存储 etcd 中。它并不直接修改 etcd，而是通过 etcd 提供的 API 进行读写操作。
- Watch 机制: API 服务器支持“Watch”机制。集群中的其他组件（如 Scheduler、Controller Manager、Kubelet 等）通过 Watch API 监听特定资源（如 Pods、Nodes）的变化。当某个资源发生变化时，API 服务器会主动通知这些监听者，从而触发相应的控制器逻辑或调度行为。
重要性: API 服务器是无状态的（本身不存储状态），但它通过 etcd 访问和修改集群的全局状态。它是整个集群各个组件协同工作的基石，任何对集群状态的修改都必须通过它。

2. etcd

角色: etcd 是一个高可用、强一致性的分布式键值存储系统，用作 Kubernetes 集群的后端数据库。它存储集群的所有配置数据、状态数据以及元数据。
工作原理:
- 单一事实来源 (Single Source of Truth): etcd 存储了集群的“期望状态”（Desired State）和“当前状态”（Current State）。所有对集群状态的修改都必须成功写入 etcd 才算生效。
- 分布式和一致性: etcd 采用 Raft 协议来保证数据在多个 etcd 节点之间的强一致性，即使部分节点故障，也能保证数据的可靠性和可用性。
重要性: etcd 是 Kubernetes 的“心脏”。如果 etcd 发生故障，集群将无法执行任何状态更新操作，甚至可能无法正常运行。因此，etcd 的高可用性和备份是生产环境中非常重要的考量。API Server 是唯一直接与 etcd 交互的 Kubernetes 组件。

3. Kube-Scheduler (调度器)

角色: 调度器负责监听 API Server，查找新创建的、但尚未分配到任何工作节点的 Pod。一旦发现这样的 Pod，调度器就会根据预定的调度策略，选择一个最适合运行该 Pod 的工作节点。
工作原理:
- 过滤 (Predicates): 调度器首先对所有符合条件的节点进行过滤。它检查每个节点是否满足 Pod 的调度要求，例如是否有足够的资源（CPU、内存）、是否满足节点亲和性/反亲和性规则、是否满足 Taint/Toleration 要求等。不满足条件的节点会被排除。
- 打分 (Priorities): 在过滤掉不合适的节点后，调度器会对剩余的符合条件的节点进行打分。打分规则考虑多种因素，如资源使用率、节点亲和性/反亲和性规则的强度、端口冲突、卷可用性等。得分最高的节点将被选中。
- 绑定 (Binding): 调度器将选中的节点信息（NodeName）更新到 Pod 的定义中，并通过 API Server 将这一信息写入 etcd。这个过程称为“绑定”。需要注意的是，调度器只是决定了 Pod 应该运行在哪个节点，实际启动 Pod 的工作是由目标节点上的 Kubelet 完成的。
重要性: 调度器是实现 Pod 自动分配和资源优化的关键组件。优秀的调度策略能够提高集群的资源利用率，并确保应用程序的可靠性。

4. Kube-Controller-Manager (控制器管理器)

角色: 控制器管理器是一组内建控制器的集合。控制器是 Kubernetes 中实现“声明式”核心逻辑的关键。它们通过监听 API Server 中对象状态的变化，并努力将集群的“当前状态”调整到对象的“期望状态”。
工作原理:
- 控制器集合: Kube-Controller-Manager 运行着多种控制器，例如：
  - Node Controller (节点控制器): 负责监控节点的状态。如果节点变得不可用，节点控制器会注意到这一点，并触发删除在该节点上运行的 Pods 的操作（如果 Pod 没有设置容忍节点故障的策略），并在其他可用节点上重新创建它们。
  - ReplicaSet Controller (副本集控制器): 负责维护特定数量的 Pod 副本。它通过监听 ReplicaSet 对象和 Pod 对象的变化，确保运行中的 Pod 数量始终等于 ReplicaSet 定义中指定的副本数。如果 Pod 数量过多，它会终止多余的 Pod；如果数量过少（例如 Pod 崩溃或节点故障），它会在其他节点上创建新的 Pod。
  - Deployment Controller (部署控制器): 负责管理无状态应用程序的部署和更新。它通过 ReplicaSet 来管理 Pods，并提供滚动更新、回滚等高级功能。
  - Service Controller & Endpoints Controller (服务控制器与端点控制器): 服务控制器负责创建云提供商的负载均衡器（如果集群运行在支持的云平台上）。端点控制器负责填充 Endpoints 对象，该对象是 Service 对应的 Pods 的 IP 地址和端口列表，供 Kube-Proxy 使用。
  - ServiceAccount & Token Controller (服务账户与令牌控制器): 负责为新的命名空间创建默认的服务账户和 API 访问令牌。
- 调谐循环 (Reconciliation Loop): 每个控制器都实现了一个调谐循环。它不断地从 API Server 获取其关注的资源对象的当前状态，与 etcd 中存储的期望状态进行对比。如果发现差异，它就会采取行动（例如创建、删除、更新 Pods 或其他资源）来消除差异，直到当前状态符合期望状态。
重要性: 控制器管理器是 Kubernetes 实现自动化运维和自愈能力的核心。它们持续不断地工作，确保集群按照用户的意愿运行。

5. Cloud-Controller-Manager (云控制器管理器 – 可选)

角色: 云控制器管理器是 Kubernetes 1.6 版本引入的组件，它将 Kubernetes 集群与底层云平台的 API 集成。如果你的集群运行在公有云（如 AWS、GCE、Azure）或私有云上，并且需要使用云提供的基础设施（如负载均衡、持久化存储卷、路由等），通常会部署这个组件。
工作原理: 它运行一些特定于云平台的控制器，例如：
- Node Controller: 检查云提供商的 API，以确定节点是否已被删除。
- Route Controller: 在云平台中配置路由，以便 Pods 之间可以在不同子网中通信。
- Service Controller: 根据 Service 定义在云平台上创建、更新和删除负载均衡器。
- Volume Controller: 创建、挂载和管理云平台提供的存储卷。
重要性: 云控制器管理器使得 Kubernetes 能够更好地利用底层云基础设施，解耦了核心 Kubernetes 代码与云平台特有的实现细节。在非云环境（裸金属或本地）安装的 Kubernetes 集群通常不需要部署这个组件。

工作节点组件 (Worker Node Components)

工作节点是应用程序实际运行的地方。每个工作节点都运行着几个关键组件，这些组件负责接收控制平面的指令，管理节点上的 Pods 和容器，并向控制平面报告节点和 Pod 的状态。

1. Kubelet

角色: Kubelet 是运行在每个工作节点上的主要代理。它接收 API Server 发送的该节点上 Pod 的定义（PodSpec），并确保这些 Pods 按照定义运行起来。
工作原理:
- 监听 API Server: Kubelet 通过 Watch API 持续监听 API Server，获取分配给它的 Pod 的信息。
- Pod 生命周期管理: 根据从 API Server 收到的 Pod 定义，Kubelet 负责执行 Pod 的各种生命周期操作：
  - 创建 Pod：与容器运行时交互，拉取容器镜像，创建并启动容器。
  - 监控 Pod：检查 Pod 中容器的状态，包括健康检查（Liveness Probe 和 Readiness Probe）。
  - 删除 Pod：终止并清理 Pod 中的容器。
- 节点状态报告: Kubelet 定期向 API Server 报告节点的资源使用情况、状态（如是否可调度、是否有故障）以及在该节点上运行的 Pods 的状态。
- CRI, CNI, CSI 集成: Kubelet 通过标准的接口与底层基础设施进行交互：
  - Container Runtime Interface (CRI): 与容器运行时（如 containerd, CRI-O, Docker 等）交互，负责容器的创建、启动、停止等。
  - Container Network Interface (CNI): 与网络插件交互，负责配置 Pod 的网络。
  - Container Storage Interface (CSI): 与存储插件交互，负责配置 Pod 的存储卷。
- 管理静态 Pods: Kubelet 也可以直接管理通过文件配置的“静态 Pods”，这些 Pods 不受 API Server 控制，通常用于运行控制平面组件自身。
重要性: Kubelet 是连接控制平面和工作节点的桥梁，它是实际执行 Pod 运行、停止、监控任务的执行者。

2. Kube-Proxy

角色: Kube-Proxy 运行在每个工作节点上，负责实现 Kubernetes Service 的网络抽象。它使得集群内部的 Pods 之间以及外部客户端能够通过稳定的 Service IP 和端口访问动态变化的 Pods。
工作原理: Kube-Proxy 监听 API Server 中 Service 和 Endpoints 对象的变化，并根据这些信息维护节点上的网络规则，将发往 Service IP 的流量转发到 Service 对应的 Pod IP。Kube-Proxy 支持多种网络模式：
- Userspace 模式 (已弃用/不推荐): Kube-Proxy 本身监听 Service IP 和端口，并将连接转发到后端 Pod。性能差。
- Iptables 模式 (默认): Kube-Proxy 利用 Linux 的 iptables 规则，直接在内核空间进行 DNAT（目标网络地址转换）。这是目前最常见和稳定的模式。当流量到达 Service IP 时，iptables 规则会将其重定向到后端 Pod 的 IP 和端口。
- IPVS 模式: Kube-Proxy 利用 Linux 的 IPVS（IP Virtual Server）进行更高级的负载均衡。IPVS 模式在大规模 Service 和后端 Pods 场景下通常比 iptables 模式具有更好的性能和可扩展性。
- Kernelspace 模式 (Windows): 在 Windows 节点上使用不同的实现机制。
重要性: Kube-Proxy 是 Kubernetes Service 实现内部负载均衡和流量路由的关键。它使得应用程序可以不用关心后端 Pod 的具体位置和数量变化，而通过稳定的 Service IP 进行访问。

3. Container Runtime (容器运行时)

角色: 容器运行时是安装在每个工作节点上，负责运行容器的基础软件。它接收来自 Kubelet 的指令，负责拉取镜像、创建容器、启动容器、停止容器等具体操作。
工作原理: Kubelet 通过 CRI（Container Runtime Interface）与容器运行时进行通信。这意味着 Kubernetes 支持多种符合 CRI 标准的容器运行时。
常见容器运行时:
- containerd: CNCF 孵化项目，由 Docker 公司贡献，是现代 Kubernetes 环境中广泛使用的默认容器运行时。
- CRI-O: 专为 Kubernetes 设计的容器运行时，专注于 CRI 实现。
- Docker Engine (通过 dockershim 兼容层): 早期 Kubernetes 主要使用 Docker Engine，但从 Kubernetes 1.20 版本起，内置的 dockershim 兼容层已被移除。如果仍需要使用 Docker Engine，需要安装外部的 dockershim 或 cri-dockerd。
重要性: 容器运行时是 Pod 中容器的实际执行环境，它的稳定性和性能直接影响应用程序的运行。

Kubernetes 组件协同工作流示例：创建一个 Pod

为了更好地理解这些组件是如何协同工作的，我们来看一个创建 Pod 的典型流程：

用户意图 (kubectl apply): 用户通过 kubectl apply -f my-pod.yaml 命令向 Kubernetes 集群提交一个 Pod 的 YAML 定义文件，表达希望在集群中运行一个 Pod 的期望。
API Server 接收与校验: kubectl 命令将 Pod 定义发送到 Kubernetes API Server。API Server 接收请求，首先进行用户认证、授权和准入控制检查。如果通过，API Server 会校验 Pod 定义的格式和内容是否合法。
etcd 存储期望状态: 如果校验成功，API Server 会将 Pod 的定义（代表期望状态）写入 etcd。此时，etcd 中记录了用户想要创建一个 Pod 的信息。
Scheduler 发现新 Pod: Kube-Scheduler 一直通过 Watch API 监听 API Server 中 Pod 对象的变化。当它发现一个新的、没有被分配到节点的 Pod 时，就会被触发。
Scheduler 进行调度: 调度器根据其内部的过滤和打分算法，为这个新 Pod 选择一个最合适的工作节点。
API Server 更新 Pod 状态 (绑定): 调度器决定节点后，它并不直接通知 Kubelet，而是通过 API Server 更新该 Pod 的状态，将选定的节点名称（nodeName 字段）添加到 Pod 定义中。这个操作也会被持久化到 etcd。
Kubelet 发现 Pod 分配: 目标工作节点上的 Kubelet 也通过 Watch API 监听 API Server 中分配给它的 Pod 对象的变化。当它发现一个 Pod 被分配到自己这个节点时，就会被触发。
Kubelet 执行 Pod 创建: Kubelet 根据获取到的 Pod 定义，执行创建 Pod 的具体步骤：
- 向容器运行时发出创建 Pod 和其中容器的请求（通过 CRI）。
- 容器运行时根据 Pod 定义（包括容器镜像、启动命令、环境变量、卷挂载等）拉取镜像（如果本地没有），创建并启动 Pod 中的容器。
- Kubelet 调用 CNI 插件为 Pod 配置网络。
- 如果 Pod 定义了存储卷，Kubelet 会调用 CSI 插件进行卷的挂载。
Kubelet 报告状态: Pod 启动后，Kubelet 会监控 Pod 的运行状态（如容器是否运行、是否通过健康检查），并通过 API Server 不断向 etcd 报告 Pod 的当前状态（例如 Running, Pending, Failed 等）。
控制器维护状态: 其他相关的控制器（如 ReplicaSet Controller）也会监听 Pod 状态的变化。如果 Pod 意外终止，ReplicaSet Controller 会发现当前运行的 Pod 数量少于期望数量，并会触发创建一个新的 Pod 的流程，从而将系统恢复到期望状态。

整个过程体现了 Kubernetes 核心的“声明式”和“调谐循环”理念：用户声明期望的状态（Pod 应该运行），控制平面（通过各种控制器和调度器）持续监控实际状态，并采取行动（如创建、调度、重启 Pod）来弥合期望状态与实际状态之间的差距。

总结 Kubernetes 架构的优势

深入理解 Kubernetes 的架构，有助于我们认识其为何如此强大：

模块化和解耦: 各个组件职责单一且清晰，它们主要通过 API Server 进行通信，这使得组件可以独立开发、升级和替换，提高了系统的灵活性和可维护性。
分布式和高可用性: 控制平面和工作节点都可以部署多个实例，核心组件如 etcd 也支持集群模式，这大大提高了整个系统的可用性和容错能力。
声明式 API 和自动化: 用户只需描述期望的状态，Kubernetes 控制平面会自动处理实现这个状态所需的复杂操作，大大降低了运维复杂度。
强大的自愈能力: 控制器持续监控集群状态，一旦发现与期望状态不符，就会自动采取纠正措施，例如重启失败的 Pod、在节点故障时迁移工作负载等。
可扩展性: API Server 的扩展机制（如 Admission Webhooks）、自定义资源定义 (CRD) 以及插件机制（CRI, CNI, CSI, Scheduler Plugins 等）使得 Kubernetes 能够轻松集成第三方工具和服务，并满足各种定制化需求。
单一事实来源: etcd 作为集群状态的唯一可信来源，保证了数据的一致性，避免了分布式系统中常见的状态冲突问题。

结论

Kubernetes 的架构是一个精心设计的分布式系统，它通过分离控制平面和工作节点、定义清晰的组件职责以及利用声明式 API 和调谐循环，实现了对容器化应用程序的强大编排和管理能力。API Server 作为核心枢纽，etcd 提供可靠的状态存储，Scheduler 负责智能调度，Controller Manager 驱动状态同步，Kubelet 在节点上执行任务，而 Kube-Proxy 则保障网络通信。这些组件相互协作，共同构建了一个健壮、灵活且高度自动化的平台。

理解 Kubernetes 的架构不仅是掌握其工作原理的基础，也是进行集群排障、性能优化、安全加固以及进行高级定制和二次开发的关键。随着云原生技术的不断发展，Kubernetes 的核心架构将继续演进，但其基本原理和组件协作模式将长期保持其重要性。掌握这些知识，对于在云原生时代构建和管理现代应用程序至关重要。