Kubernetes系列：核心组件简介

type

status

date

slug

summary

1、概述

Kubernetes 的核心组件如下所示，这些核心组件协同工作以实现集群管理和资源调度。

Api Server：集群的统一入口，负责暴露 Kubernetes API。

Kubernetes Controller Manager：运行一系列控制器，确保集群状态和预期一致。

Scheduler：把 Pod 调度到合适的 Node 上。

Etcd：存储集群的所有配置和数据。

Container Runtime：Pod 的底层容器实现。

Cloud Controller Manager：可选，对接云服务商的控制器。

2、Api Server

Kubernetes API Server 是 Kubernetes 控制平面的核心组件，负责暴露 Kubernetes 的 API，并作为集群内部和外部通信的中央枢纽。API Server 是所有集群操作的入口点，所有集群操作都必须通过它，负责处理 RESTful 请求、验证权限、处理数据持久化（与 etcd 交互），并协调其他组件的工作，其设计保证了集群状态的一致性和安全性。

Api Server 提供以下核心功能：

API 暴露

提供 Kubernetes 的 RESTful API（如 GET /api/v1/pods），支持通过 HTTP/HTTPS 访问。
客户端工具（如 kubectl）或应用程序通过 API Server 与集群交互。

请求处理与验证

认证（Authentication）：验证用户/服务的身份（如 TLS 证书、Bearer Token、OIDC 等）。
鉴权（Authorization）：检查是否有权限执行操作（如 RBAC、ABAC）。
准入控制（Admission Control）：动态修改或拒绝请求（如 ResourceQuota、PodSecurityPolicy）。

协调与通知：其他组件通过 API Server 监听资源变化（Watch 机制），并作出响应。

kubectl：直接向 API Server 发送请求（如 kubectl get pods）。
Controller Manager：通过 API Server 监听资源变化并执行控制循环。
Scheduler：通过 API Server 获取未调度的 Pod，分配节点后更新结果。
kubelet：定期从 API Server 获取分配给本节点的 Pod 清单，并管理容器。

数据持久化：所有集群状态（如 Pod、Service 配置）通过 API Server 持久化到分布式键值存储 etcd。这意味着只有 Api Server 会直接连 etcd，同时 Api Server 本身做了缓存、限流等优化，可以减少 etcd 的并发压力。

Api Server 的整体架构如下所示：

以使用 yaml 文件创建资源为例，Api Server 的工作流程如下：

用户运行 kubectl apply -f pod.yaml。

API Server 接收请求，验证权限并检查 YAML 合法性。

数据被保存到 etcd。

Scheduler 通过 API Server 发现未调度的 Pod，分配节点后更新 Pod 信息。

目标节点上的 kubelet 监听到变化，启动容器。

常见 API 访问方式：

kubectl：命令行工具（底层调用 API）。

客户端库：如官方提供的 client-go（Go 语言）。

直接 HTTP 请求：

3、Kubernetes Controller Manager

Controller Manager

Controller Manager 是一个守护进程，集成了多个控制器的运行时环境，是这些控制器的“容器”。它的主要职责是：

启动和管理所有内置控制器：如 Deployment、ReplicaSet、Namespace 控制器等。

提供共享的基础设施：如访问 APIServer 的客户端、认证、缓存等，避免每个控制器重复实现。

确保控制器的高可用性：例如通过 Leader Election 机制，防止多实例竞争。

目前 Kubernetes 提供了两种 Controller Manager：

kube-controller-manager：管理 Kubernetes 核心控制器（如 Deployment、Node、Service 等）。

cloud-controller-manager：管理与云平台相关的控制器（如 LoadBalancer、存储卷等，需云厂商实现）。

Controller Manager 和 Controller 的关系是什么？

Controller Manager：包含多个 Controller，是控制器的“集合体”和运行时管理者，负责控制器的生命周期管理（启动/停止）、资源隔离和通用功能复用。

Controller：专注于特定资源的调协逻辑（如处理 Pod 副本数）。

如果将 Controller 比作“工人”（负责具体任务），Controller Manager 就是“工头”（负责分配任务和管理工人）。

Controller

Kubernetes Controller（控制器）负责确保集群的实际状态与用户声明的期望状态保持一致。它是一个持续运行的控制循环，监控集群中资源的状态，比较当前状态与期望状态的差异，并执行操作使当前状态向期望状态转变。

Controller 的核心功能：

自我修复：自动重启失败的容器、替换不可用的节点等

扩缩容：根据负载自动调整应用实例数量

滚动更新：实现零停机部署应用新版本

状态维护：确保系统始终符合用户定义的规格

常见内置控制器类型：

Deployment Controller：管理无状态应用，通过 ReplicaSet 控制 Pod 副本数量，支持滚动更新和回滚

StatefulSet Controller：管理有状态应用，为 Pod 提供稳定的网络标识和持久存储，保证有序部署和扩展

DaemonSet Controller：确保所有(或特定)节点运行一个 Pod 副本，常用于日志收集、监控等系统服务

Job/CronJob Controller：Job管理一次性任务，CronJob管理定时任务

Horizontal Pod Autoscaler (HPA)：根据CPU/内存等指标自动扩缩Pod数量

4、Scheduler

Kubernetes Scheduler（调度器）负责决定将新创建的 Pod 分配到集群中的哪个节点上运行。

Scheduler 的工作流程：

监听 API Server 中未调度的 Pod（PodSpec.nodeName 为空的 Pod）

筛选出符合 Pod 运行要求的候选节点

评分并对候选节点进行排序

绑定将 Pod 分配到最优节点（通过更新 Pod 的 nodeName 字段）

调度流程

以 Deployment 的调度流程为例：

用户创建 Deployment

Deployment 控制器创建 ReplicaSet

ReplicaSet 控制器创建 Pod（未指定 NodeName）

调度器发现未调度的 Pod。

执行筛选和评分，选择最优的 Node 并绑定。

筛选阶段：排除不符合 Pod 要求的 Node，考虑因素包括：

节点资源是否充足（CPU、内存）
端口冲突
节点选择器（nodeSelector）匹配
亲和性/反亲和性规则（affinity/anti-affinity）
污点和容忍（Taints and Tolerations）
节点状态（是否 Ready 等）

评分阶段：对通过筛选的节点进行评分（0-10分），考虑因素包括：

资源平衡（优先选择资源使用率较低的节点）
亲和性优先级
数据本地性（优先已有所需数据的节点）
用户自定义优先级规则

kubelet 监控到有分配给本 Node 的 Pod，开始创建容器。

调度策略示例

自定义调度

Kubernetes 支持多种方式扩展调度功能：

调度器扩展（Scheduler Extender）：通过 webhook 方式扩展筛选和评分逻辑

多调度器：可以运行多个调度器实例，为 Pod 指定调度器

调度框架（Scheduling Framework）：插件化架构，可以开发自定义调度插件

5、Etcd

etcd 是一个基于 Raft 算法的分布式、高可用的键值存储系统，用于存储 Kubernetes 集群的所有关键数据。例如 Node、Pod、ConfigMap、Secret等信息。

etcd 负责的功能：

集群状态存储：存储所有 Kubernetes 对象（Pods、Services、Deployments 等）的状态，保存集群的配置信息

服务发现：帮助 Kubernetes 组件发现彼此，存储服务端点信息

协调与领导选举：用于 Kubernetes 控制平面组件的领导选举，确保集群操作的顺序一致性

etcd 使用类似于文件系统的层级键空间，Kubernetes 使用前缀来组织不同资源：

/registry/pods - 存储 Pod 信息

/registry/services - 存储 Service 信息

/registry/deployments - 存储 Deployment 信息

6、Container Runtime

Container Runtime（容器运行时）是负责管理和运行容器的基础组件，负责拉取容器镜像、创建/启动/停止容器、管理容器生命周期等底层操作。

容器运行时的工作流程如下：

kubelet 通过 CRI（Container Runtime Interface）与容器运行时交互。

容器运行时根据 kubelet 的指令，从镜像仓库拉取镜像。

创建并运行容器，分配资源（CPU、内存等）。

监控容器状态，处理容器的启动、停止、删除等操作。

容器运行时的实现

Kubernetes 通过 CRI（Container Runtime Interface） 标准化了与容器运行时的交互接口，支持多种运行时：

Docker（已弃用）：早期默认的运行时，但 Kubernetes 从 v1.20 开始弃用内置的 dockershim，转向更通用的 CRI 标准。替代方案：使用 cri-dockerd（适配 Docker 到 CRI 的桥接工具）。

Containerd：当前主流的容器运行时，由 Docker 分离出的轻量级核心组件。直接支持 CRI，无需额外适配。高性能、稳定性强，适合生产环境。

CRI-O：专为 Kubernetes 设计的轻量级运行时，符合 CRI 标准。专注于 K8s 兼容性，资源占用少，适合最小化部署。常用于 OpenShift 等 Kubernetes 发行版。

其他运行时

Mirantis Container Runtime（原 Docker Enterprise）：商用容器运行时，以前称为 Docker 企业版。
Kata Containers：安全隔离的运行时，基于虚拟机（VM）技术。
gVisor：谷歌开发的用户态内核，提供额外安全性。

容器运行时的选择建议：

默认推荐：containerd（生产环境首选，性能好且稳定）。

轻量级/K8s 专用：CRI-O。

需要兼容旧 Docker 工具链：cri-dockerd。

高安全需求：Kata Containers 或 gVisor（但性能会有损耗）。

Docker 和 Containerd 的关系

Docker 本身是一个完整的容器平台，包含 containerd 作为底层运行时。Kubernetes 现在直接调用 containerd，跳过 Docker 的冗余层。

配置容器运行时

在 Kubernetes 节点上，需在 kubelet 的配置中指定容器运行时：

对于 containerd，默认的 CRI 套接字路径是 unix:///run/containerd/containerd.sock。

对于 CRI-O，路径是 unix:///var/run/crio/crio.sock。

使用 kubelet 检查当前运行时

7、Cloud Controller Manager

Cloud Controller Manager (CCM) 是 Kubernetes 的一个控制平面组件，它将特定于云平台的逻辑从 Kubernetes 核心代码中分离出来。

为什么需要 CCM？在 Kubernetes 早期版本中，云提供商代码直接集成在 Kubernetes 核心组件(kube-controller-manager 和 kubelet)中。这种设计导致：

核心 Kubernetes 代码与云提供商代码紧密耦合

云提供商需要修改核心 Kubernetes 代码来添加新功能或修复问题

增加了核心 Kubernetes 的维护复杂性

CCM 通过解耦这些功能解决了这些问题。CCM 可以作为独立的 Pod 运行在控制平面，也可以作为 DaemonSet 部署。主流云提供商(如 AWS、Azure、GCP 等)都提供了自己的 CCM 实现。CCM 提供的功能包括：

节点控制器(Node Controller) - 检查云提供商以确定节点是否已在云中停止运行后从集群中删除

路由控制器(Route Controller) - 在底层云基础设施中配置路由

服务控制器(Service Controller) - 创建、更新和删除云提供商负载均衡器

卷控制器(Volume Controller) - 与云提供商交互以管理持久卷

CCM 的工作原理：CCM 实现了多个控制器，这些控制器通过云提供商的API观察集群状态变化并做出相应调整。例如：

当创建 LoadBalancer 类型的 Service 时，服务控制器会调用云API创建负载均衡器

当节点不可用时，节点控制器会检查云提供商以确认节点状态