一、Kubernetes的整体架构¶

k8s遵循主从架构，分为Master节点和Node节点，Master节点是控制节点，Node节点是工作节点。其中，Master节点包含kube-apiserver、kube-scheduler、kube-controller-manager、etcd、kubelet、kube-proxy；Node节点包含kubelet、kube-proxy。

k8s高可用架构图

二、Master节点与控制平面¶

指容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。管理集群中的工作节点和 Pod。在生产环境中，控制平面通常跨多台计算机运行，一个集群通常运行多个节点，提供容错性和高可用性。

注意:Master节点数量没有硬性要求!

2.1 kube-apiserver¶

API 服务器是 Kubernetes 控制平面的组件，该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

2.2 etcd¶

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。一般可以安装在Master节点上，如果资源充足，也可安装到单独的服务器上。

注意:Etcd数据库数量必须保持奇数个，防止发生脑裂!

2.3 kube-scheduler¶

kube-scheduler 是控制平面的组件，通过api-server监视新创建的、未指定运行节点node的 Pods，并选择节点来让 Pod 在上面运行。

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

kube-scheduler 也分为主从节点，不像api-server所有节点都在工作，真正的工作节点只有一个。

针对1.24以及1.24之前的版本可通过以下命令查看kube-scheduler 部署情况

$ kubectl get leases -n kube-system
NAME                      HOLDER                                              AGE
kube-controller-manager   k8s-master02_7df9a5ea-67f9-453b-9b9e-7963376bfa86   2d14h
kube-scheduler            k8s-master02_3e7fc8c0-74f6-4998-94d0-a2d62bdaa57a   2d14h

2.4 kube-controller-manager¶

kube-controller-manager 是控制平面的组件，负责运行控制器进程。

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）

kube-controller-manager 也分为主从节点，不像api-server所有节点都在工作，真正的工作节点只有一个。

针对1.24以及1.24之前的版本可通过以下命令查看kube-controller-manager 部署情况

$ kubectl get leases -n kube-system
NAME                      HOLDER                                              AGE
kube-controller-manager   k8s-master02_7df9a5ea-67f9-453b-9b9e-7963376bfa86   2d14h
kube-scheduler            k8s-master02_3e7fc8c0-74f6-4998-94d0-a2d62bdaa57a   2d14h

2.5 kubelet¶

kubelet 会在集群中每个节点(node)上运行。它保证容器containers都运行在 Pod 中。这里之所以放在Master节点组件里面，客观上说Master也属于node。

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

简单来说，就是负责与Master节点通信协作，管理本节点上的Pod,对容器进行健康检查，上报节点和节点上Pod的状态。

2.6 kube-proxy¶

kube-proxy是集群中每个节点(node)上所运行的网络代理，实现 Kubernetes 服务(Service)概念的一部分。

kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

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

简单来说，就是负责各Pod之间的通信和负载均衡，将流量分发到后端机器上。

三、Node节点核心组件¶

托管 Pod，而 Pod 就是作为应用负载的组件,是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。每个集群至少有一个工作节点。

3.1 kubelet¶

kubelet 会在集群中每个节点(node)上运行。它保证容器containers都运行在 Pod 中。这里之所以放在Master节点组件里面，客观上说Master也属于node。

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

简单来说，就是负责与Master节点通信协作，管理本节点上的Pod,对容器进行健康检查，上报节点和节点上Pod的状态。

3.2 kube-proxy¶

kube-proxy是集群中每个节点(node)上所运行的网络代理，实现 Kubernetes 服务(Service)概念的一部分。

kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

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

简单来说，就是负责各Pod之间的通信和负载均衡，将流量分发到后端机器上。

3.3 Runtime¶

容器运行环境是负责运行容器的软件。

四、常见集群插件¶

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

4.1 CoreDNS¶

用于Kubernetes 内部service的解析，可以让pod解析Service名称，从而通过Service解析后的IP地址进行连接到对应的应用。

4.2 Dashboard¶

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身，并进行故障排除。

4.3 Calico¶

符合CNI标准的一个网络插件，负责给每个Pod分配一个不会重复的IP。和它有类似功能的有fannel，二者最大的区别就是Calico支持网络策略，fannel不支持网络策略。

Kubernetes架构组成与核心组件