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的唯一入口

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

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