K8S 是属于主从设备模型（Master-Slave 架构），即有 Master 节点负责核心的调度、管理和运维，Slave 节点则执行用户的程序。

一、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， Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node 上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候，Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。
• 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工作流程

用K8S部署Nginx的过程中，K8S内部各组件是如何协同工作的：
我们在master节点执行一条命令要master部署一个nginx应用(kubectl create deployment nginx --image=nginx)

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

总结

提示：以上就是今天要讲的内容，本文仅仅简单介绍了K8S 核心架构原理。