🏷️个人主页：牵着猫散步的鼠鼠 

🏷️系列专栏：Kubernetes渐进式学习-专栏

🏷️个人学习笔记，若有缺误，欢迎评论区指正 

目录

1. 前言

2. K8S的前身-Borg

3. 集群架构

3.1. 控制面板组件(Master)

3.1.1. kube-apiserver

3.1.2 kube-controller-manager

3.1.3 cloud-controller-manager

3.1.4 kube-scheduler

3.1.5 etcd

3.2. 节点组件(Node)

3.2.1  kubelet

3.2.2 kube-proxy

3.2.3 container runtime

4. 分层架构

4.总结

---

1. 前言

我们在前面的文章中讲解了什么是Kubernetes，以及为什么需要Kubernetes，接下来我们继续学习Kubernetes的相关核心概念-集群架构与组件，本章内容主要是讲解Kubernetes的内部组成架构以及一些相关组件的定义，理解这些内容更方便我们后续学习具体的操作。

2. K8S的前身-Borg

在讲解K8S的架构前，我们首先了解下K8S的前身Borg，Borg是Google的内部大型集群管理系统，这个大型集群管理系统算是Kubernetes的前身。Borg的架构图如下：

1. BorgMaster：BorgMaster是Borg系统的中心控制节点，负责管理整个集群的状态和调度任务。它维护了集群的配置信息、资源分配情况、任务状态等，并处理来自客户端的请求。BorgMaster还负责处理集群中的故障和异常情况，确保系统的稳定性。

2. Borglet：Borglet是运行在每个节点上的代理程序，负责管理节点上的任务和资源。它接收来自BorgMaster的指令，启动或停止任务，管理任务的运行状态，并收集节点上的资源使用情况。Borglet还负责处理节点上的故障和异常情况，确保节点的稳定性。

3. BorgScheduler：BorgScheduler是Borg系统中的调度器，负责根据任务的需求和资源的情况，选择合适的节点来运行任务。它采用了多种调度策略，如优先级调度、资源需求匹配等，以确保资源的合理利用和任务的快速响应。

4. BorgClient：BorgClient是客户端程序，用户通过BorgClient与Borg系统进行交互。。如上的borgcfg，command-line-tools，web browsers都可以算为BorgClient。

3. 集群架构

如上为K8S的架构图， 我们可以看到分为了控制面板组件(Master)和节点组件(Node)，我们接下来就针对这两大类进行讲解

3.1. 控制面板组件(Master)

3.1.1. kube-apiserver

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

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

3.1.2 kube-controller-manager

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

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

这些控制器包括：

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

3.1.3 cloud-controller-manager

嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

3.1.4 kube-scheduler

scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；

3.1.5 etcd

一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。

如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。

你可以在官方文档中找到有关 etcd 的深入知识。
早期数据存放在内存，现在已经是持久化存储的了。

3.2. 节点组件(Node)

3.2.1  kubelet

kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；

3.2.2 kube-proxy

kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

3.2.3 container runtime

Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

此外还有一些像Prometheus，Dashboard等附加组件，这里就不展开讲了。

4. 分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示

生态系统：

在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：

• Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
• Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）
核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境

4.总结

本文简单的介绍了K8S集群架构和组件，尚未深入(鼠鼠也不造啊)，想要了解更细致的内容可以阅读官网Kubernetes（k8s）中文文档 Kubernetes设计架构_Kubernetes中文社区。