K8S核心架构原理

置顶福海鑫森

已于 2022-06-29 12:04:11 修改

阅读量1.3k

点赞数 1

分类专栏： Kubernetes 文章标签： kubernetes

于 2012-11-23 13:36:38 首次发布

原文链接：https://blog.csdn.net/taotao_guiwang/article/details/121034438

版权

Kubernetes 专栏收录该内容

16 篇文章 1 订阅

订阅专栏

K8S 的核心功能：自动化运维管理多个容器化程序。

在这里插入图片描述
K8S是属于主从设备模型（Master-Slave架构），即有Master节点负责核心的调度、管理和运维，Slave节点则执行用户的程序。但是在K8S中，主节点一般被称为Master Node 或者 Head Node，而从节点则被称为Worker Node 或者 Node。
注意：Master Node 和Worker Node是分别安装了K8S的Master和Worker组件的实体服务器，每个Node都对应了一台实体服务器（虽然Master Node可以和其中一个Worker Node安装在同一台服务器上，但建议Master Node单独部署），**所有Master Node和Worker Node组成K8S集群，**同一个集群可能存在多个Master Node和Worker Node。

首先来看Master Node都有哪些组件：

API server：K8S的请求入口服务。 API Server 负责接收K8S所有的请求（来自UI界面或者CLI命令行工具），然后，API Server根据用户的具体请求，去通知其他组件干活。
Scheduler：K8S所有Worker Node 的调度器。

当用户要部署服务时，Scheduler会选择最合适的Worker Node（服务器）来部署。
Controller Manager：K8S所有Worker Node的监控器。

Controller Manager有很多具体的Controller：等。

Controller负责监控和调整在Worker Node上部署的服务的状态，比如用户要求A服务器部署两个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。

Controller Manager 就是集群内部的管理控制中心，由负责不同资源的多个 Controller （Node Controller、Service Controller、Volume Controller、RS Controller ）构成，共同负责集群内的 Node、Pod 等所有资源的管理，比如当通过 Deployment 创建的某个 Pod 发生异常退出时，RS Controller 便会接受并处理该退出事件，并创建新的 Pod 来维持预期副本数。

Certificate Controller
ClusterRoleAggregation Controller
Node Controller
CronJob Controller
Daemon Controller
Deployment Controller
StatefulSet Controller
Endpoint Controller
Endpointslice Controller
Garbage Collector
Namespace Controller
Job Controller
Pod AutoScaler
PodGC Controller
ReplicaSet Controller
Service Controller
ServiceAccount Controller
Volume Controller
Resource quota Controller
Disruption Controller

etcd：K8S的存储服务。 etcd存储了K8S的关键配置和用户配置，K8S中仅API Server才具备读写权限，其它组件必须通过API Server的接口才能读写数据。
接下来看Worker Node的组件：

Kubelet。Worker node的监视器，以及与Master Node的通讯器。
Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行服务的状态，并接受来自Master Node的指示采取调整措施。负责控制所有容器的启动停止，保证节点工作正常。
Kube-Proxy。K8S的网络代理。 Kube-Proxy负责Node在K8S的网络通讯、以及对外网络流量的负载均衡。
**Container Runtime。Worker Node的运行环境。**即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine运行环境。
在大概理解了上面几个组件的意思后，我们来看下上面用K8S部署Nginx的过程中，K8S内部各组件如何协同工作的：
我们在master节点执行一条命令要master部署一个nginx应用（）

kubectl create deployment nginx --image=nginx

这条命令首先发到master节点的网关api server，这是master的唯一入口

api server将命令请求交给controller manager进行控制
controller manager进行应用部署解析,controller manager会生成一次部署信息，并通过api server将信息存入etcd存储中
scheduler调度器通过api server从etcd存储中拿到要部署的应用，开始计算那个节点有资源适合部署，scheduler把计算出来的调度信息通过api server再放到etcd中
每一个node节点的监控组件kubelet，随时和master保持联系（给api-server发送请求不断获取最新数据），拿到master节点存储在etcd中的部署信息
假设node2的kubelet拿到部署信息，显示他自己节点要部署某某应用
node和master也是通过master的api-server组件联系的,kubelet就自己run一个应用在当前机器上，并随时给master汇报当前应用的状态信息,
每一个机器上的kube-proxy能知道集群的所有网络，只要node访问别人或者别人访问node，node上的kube-proxy网络代理自动计算进行流量转发。

————————————————
版权声明：本文为CSDN博主「core815」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/taotao_guiwang/article/details/121034438