k8s从初识到上天系列第二篇：kubernetes的组件和架构

迈不过友情╰ 2024-05-24 12:53 72阅读 0赞

> ?? **欢迎加入我们的学习交流群呀！**
> 
> ✅✅1：这是**孙哥suns**给大家的福利！
> 
> ✨✨2：我们**免费分享Netty、Dubbo、k8s、Mybatis、Spring、SpringSecurity、Docker、Grpc、各种MQ、Rpc、SpringCloud**等等很多**应用和源码级别高质量视频和笔记资料**，你想学的我们这里都有！
> 
> ??3：QQ群：**583783824** ?? 工作VX：**BigTreeJava** 拉你进VX群，免费领取！
> 
> ??4：以上内容，进群免费领取呦~ ????
> 
> ??5：**学完帮你进大厂~~**

## 一：kubernetes组件 ##

### 1：集群组件概述 ###

**官方说法：**

当部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为节点， 会运行容器化应用程序。 每个集群至少有一个工作节点 。工作节点会 托管Pod ，而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和Pod。

**说人话版本：**

**集群：cluster，多个几点被组织到一起共同为系统提供服务过程称之为集群。本质上是将承载同一个软件服务节点组织到一起，称之为该软件(服务)的集群，当然集群中的节点身份地位是不一样的。**

**k8s集群也是如此，他也是多个节点组成。不过，在k8s世界中，一组工作的机器才被称之为节点。**

**k8s集群中有多个节点，我们一般建议是三个节点。三个节点有两种，第一种是Control Plane控制节点，这个类似于我们常规理解的master节点，第二种节点是work node节点类似于我们常规理解的slave。**

**控制节点主要是负责调度的，他主要是负责容器的管理和资源分配。真正的work节点才是真正运行咱们得应用程序容器的。**

**k8s管理的单元不是容器而是Pod，Pod不是容器，Pod相当于是给容器进行了包裹。一个Pod里边可以运行多个容器。Pod就是负载组件，控制平台管理集群中的工作节点和Pod**

![e6e63e28ae184e7989aef07678444a67.png][]· 官方给的这个图：左侧是控制平面组件，右侧是我们的工作节点，一共有三个，工作节点是用来真正运行工作容器的。

控制节点上边就是运行了一堆k8s的组件，后边我们都会分享。

### 2：控制平面组件 （Control Plane Components） ###

**官方版：**

控制平面组件会为集群做出全局决策，比如资源的调度。以及检测和响应集群事件，例如当不满足部署的replicas字段时，要启动新的 pod

**说人话版：**

**控制平面组件这个组件就是管调度的。检测、资源调度等等。**

**控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此物理机上运行用户容器，也就是Master上不会跑Pod。**

#### **(一)：kube-apiserver** ####

官方版：

API server是 Kubernetes 控制平面的组件，该组件负责公开了Kubernetes API，负责处理接受请求的工作。API server是 Kubernetes控制平面的前端。Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行kube-apiserver 的多个实例，并在这些实例之间平衡流量。

**说人话版：**

**说白了就是操作k8s的集群的API总入口，我们操作整个的k8s集群需要些写一些命令，这些命令会优先会被apiserver接收到，我们通过Rest或者是命令的方式去调度就行了。他就是控制平面组件的总入口，就是接口用户命令的。API Server是控制平台组件的前端，但是他的真正底层实现是基于接口实现的方式，基于kube-apiserver他可以通过部署多个实例来进行扩缩，在诸多实例中实现流量平衡。**

**这玩意就是接收命令请求的。**

#### **(二)：etcd** ####

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

**这里边存储的是集群元数据，所谓元数据就是记录集群信息的，类似于MySQL数据库，information\_schema下的数据。**

#### **(三)：kube-scheduler** ####

官方说法：

kube-scheduler是控制平面的组件，负责监视新创建的、未指定运行节点node的 Pods， 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

#### **(四)：kube-controller-manager** ####

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

这些控制器包括：

节点控制器(Node Controller)：负责在节点出现故障时进行通知和响应。

任务控制器(Job Controller)：监测代表一次性任务的Job 对象，然后创建 Pods 来运行这些任务直至完成。

端点分片控制器(EndpointSlice controller)：填充端点分片(EndpointSLice)对象(以提供 Service 和 Pod 之间的链接)。

服务账号控制器(ServiceAccount controller)：为新的命名空间创建默认的服务账号(ServiceAccount)

**(五)：cloud-controller-manager**

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

**cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。**

**下面的控制器都包含对云平台驱动的依赖:  
节点控制器(Node Controller):用于在节点终止响应后检查云提供商以确定节点是否已被删除。**

**路由控制器(RouteController):用于在底层云基础架构中设置路由**

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

如果咱们使用云平台的话，一般云平台中都直接选用现成的k8s集群使用。这个目前研究太深意义不大。

[e6e63e28ae184e7989aef07678444a67.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/24/ef9f08e461c04af9860dfe95b713e38c.png