Kubernetes的工作原理是什么

荚是Kubernetes中最小的可部署的计算单元

这样的一组容器被“打”包到一起组成了一个豆荚并接受Kubernetes的调度,编排等控制逻辑。

为了让大家更好的理解”一组容器”的概念,接下来为大家详细剖析Pod的内部架构。

<强>荚的内部架构

蓝色部分代表的是整个豆荚。其中右上角的名称空间是净舱级别的名称空间,它代表了豆荚中的所有容器。

图中有4个集装箱(即:PauseContainer/集装箱/容器B/C/容器),他们在创建的时候都被加入到当了名称空间中。

那么,Pod级别的容器是从哪里来的呢?从图中可以看的到,真正工作的容器我们把它标注为A, B, C.Pause容器的作用相当于一个占位符。当我们创建Pod的时候,会首先创建一个暂停容器。该容器创建出来的名称空间,就相当于整个吊舱的名称空间。然后后面的容器再创建出来(比如说容器A/B/C)这些容器在创建出来的时候,就都会选择加入到暂停容器创建出来的网络名称空间当中。

当然,也不是所有的名称空间都是不隔离的.Container左侧是一个形象,每一个容器都有一个镜像,每一个镜像又相当于一个容器的根ffs。既然每个容器的根ffs是不相同的,那么显而易见,mnt名称空间就是隔离的。

这样我们就可以清楚地看,到哪些namespce在豆荚当中是互相隔离的,而哪些是在,舱级别当中共享的。

<强>荚在Kubernetes中的展现形式

通常,我们习惯用Yaml来描述Kubernetes里的资源.Yaml中的内容其实就是我们对资源参数的描述。

我们先看Pod在Yaml中的前四行。这四行是资源在Yaml中的通用字段.ApiVersion/一种用于表示Kubernetes的资源类型是什么。通过元数据来声明资源的源数据.Spec字段和资源类型是强相关的了。不同的资源会有不同的规范定义。那在豆荚资源当中,最核心的是关于容器的定义了。

下面几行,关于容器的定义,是一个数组类型的,这也符合我们对吊舱的定义,即它是由一组容器形成的。这些字段包含:声明容器镜像,启动容器的命令,容器镜像的拉取方式,以及容器的名称。

<强> 1.2核心概念Kubelet

Kubelet是Kubernetes集群的“节点代理”。也可以说是Kubernetes部署在每个节点的代理。

Kubelet启动后会向Kubernetes集群注册自己,并上报节点的相关信息。此时在Kubernetes集群中就增加了一台新的可用的节点节点(可能是一个物理机,也可能是一个虚拟机,甚至是一个容器)。

Kubelet发现有属于自己节点的圆荚体符合创建条件后,会按照Pod声明的配置去启动容器。

<强> <强> 1.3,Kubernetes控制面的相关组件

上面这张图分为3个部分作介绍:

1。下半部分:也就是之前介绍过的Kubelet/Pod。

2。左上角:Kubectl。也就是Kubernetes的命令行工具。可以通过Kubectl来提交资源的Yaml给Kubernetes集群。也可以进行一系列的运维操作。

3。右面:主节点。也就是Kubernetes控制面的相关组件了。其中,API服务器是Kubernetes中所有源数据的集成入口。也是整个Kubernetes集群的中枢组件。其他组件(包括控制器,调度器等)在获取数据都需要和API服务器打交道.API切断也会接受这些组件的协入请求,并最终将数据写入ETCD当中,同时,API服务器也会缓存所有的源数据。当其他组件发起“读”请求时,就会将数据直接从内存中发给对方。尽量避免ETCD成为系统的瓶颈。除了源数据存储功能,API服务器还提供了一个看机制。能够主动推送某种资源的变化。而调度器会向API切断注册并且监听Pod的资源变更事件.Scheduler整体的调度逻辑可以简化并概括为两个:过滤,打分。

每次对Pod进行调度的时候,首先将不符合条件的节点(如:机器上已经没有资源了,不符合某些标签,选择器的要求等)过滤掉。过滤完成后我们得到一个符合要求的节点列表,调度器,会通过打分算法,来计算每一个节点的分数。最终选择一个得分最高的节点做为吊舱需要绑定的节点。最终调度程序会将结果回写到API服务器当中。

Kubernetes的工作原理是什么