---

前言

一个完整的 K8s 集群由一组节点（node）服务器组成，这些服务器节点运行着 K8s 所管理的容器化应用，且每个集群至少有一个工作节点（work node）。工作节点会托管所有的 Pods，而 Pod 就是作为应用负载的组件。

控制平面管理集群中的工作节点和 Pods，为集群提供故障转移和高可用性。

基础架构：

一、控制平面组件

控制平面组件会为集群做出全局决策（如：集群资源调度、检测和响应等），控制节点可以在集群中的任何节点上运行，接下来看看控制平面组件都有哪些。

1.1 kube-apiserver

该组件负责公开 K8s API，负责 API 请求处理，提供了资源操作的唯一入口（如认证、授权、访问控制、API 注册等），是 K8s 的前端控制平面组件。

kube-apiserver 可进行水平扩/缩容（通过部署多个 kube-apiserver 实例来实现），实现多 kube-apiserver 实例的流量平衡。

1.2 etcd

etcd 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库，它保存了整个 K8s 集群的状态。

通常，我们也要对 ETCD 集群做相关备份工作，更多 ETCD 相关内容可阅读其官方文档

1.3 kube-scheduler

该组件负责资源调度，如监视新创建的、未指定运行节点（node） 的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰等。

1.4 kube-controller-manager

该组件负责运行控制器进程，从逻辑上讲，每个控制器都是单独的一个进程，但是为了降低复杂性，这些控制器都被编译到同一个可执行文件，并在同一个进程中运行。负责维护集群状态，如故障检测、自动扩展、滚动更新等。

控制器主要包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应；
• 任务控制器（Job Controller）：负责检测一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成；
• 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象，即加入 Service 与 Pod；
• 服务账户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌。

1.5 cloud-controller-manager

该组件是指嵌入特定云的控制逻辑控制平面组件，允许你将 K8s 集群连接到云提供商的 API 上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

二、Node 组件

2.1 kubelet

该组件运行在 K8s 集群中的每个 work 节点上，保证容器都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。

2.2 kube-proxy

该组件运行在 K8s 集群中的每个 work 节点上，是集群中每个 work 节点上运行的网络代理，负责维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

2.3 Container Runtime

该组件是容器运行时，是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 Docker、Containerd、CRI-O 等。