Kubernetes的组件有哪些
引用：https://www.cnblogs.com/smail-bao/p/11995923.html
引用：https://www.cnblogs.com/zhangpeiyao/p/13521103.html
引用：https://blog.csdn.net/qq_37896194/article/details/98874068
k8s集群架构：
一个K8S集群是由两大部分组成：
Master节点和Node节点
1，Mater节点主要包括API Server,Scheduler,Controller Manager,etcd几大组件。
1.1，API Server(提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接和etcd进行交互）
K8s及群众，API Server扮演者通信枢纽的位置。API Server不仅负责和etcd交互（其他组件不会直接操作etcd，只有API Server直接操作etcd)，并且对外提供统一的API调用入口，所有的交互都是以API Server为核心的。API Server提供了以下的功能：
1.1.1，整体集群管理的API接口：所有对集群进行的查询和管理都要通过API来进行。集群内部的组件（如kubelet)也是通过API Server更新和同步数据到etcd中。
1.1.2，集群内部各个模块之间通信的枢纽：所有模块之间并不会相互调用，二十通过和API Server打交道来完成自己那部分的工作。
1.1.3，集群安全控制：API Server提供的验证和授权保证了整个集群的安全。
1.1.4，数据中心枢纽：API Server负责和etcd交互存放集群用到的运行数据。
1.2，Scheduler（负责对集群内部的资源进行调度，相当于“调度室”）
Scheduler负责节点资源管理，接收来自kube-apiserver创建pods的任务，收到任务后它会检索出所有符合该pod要求的node节点（通过预选策略和优选策略），开始执行pod调度逻辑。调度成功后将Pod绑定到目标节点上。
1.3，Controller Manager
controller-manager 作为k8s集群的管理控制中心，负责集群内Node，Namespace，Service，Token，Replication等资源对象的管理，使集群内的资源对象维持在预期的工作状态。每一个controller通过API Server提供的restful接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复到于其的工作状态，常见的controller有Namespace controller，Node controller，Service controller，ServiceAccount controller，Token controller，ResouceQuote controller，Replication controller等。
1.4，Etcd
etcd在k8s集群是用来存放数据并通知变动的。
k8s中没有用到数据库，它把关键数据都存放在etcd中，这使k8s的整体结构变得非常简单。k8s中，数据是随时发生变化的，比如说用户提交了新任务，增加了新的node，Node宕机了，容器死掉了等等，都会触发数据状态的变更。护具状态变更了之后呢，Mster上的kube-scheduler和kuke-controller-manager，就会重新安排工作，它们的工作安排结果也是数据。这些变化，都需要及时地通知给每一个组件。etcd有一个特别好用的特性，k8s中的每个组件只需要监听etcd中数据，就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排写入到etcd中就可以了，不用自己费心去逐个通知了。
2，Node节点主要包括kubelet，kube-proxy模块和pod对象
2.1，Pod是k8s最基本的操作单元。一个pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
2.2，kubelet 运行在每个计算节点上
kubelet组件通过api-server提供的接口检测到kube-scheduler产生的pod绑定事件，然后从etcd获取pod清单，下载镜像并启动容器。
同时监视分配给该Node节点的pods，周期性获取容器状态，再通过api-server通知各个组件。
3，kube-proxy
首先k8s里所有资源都存在于etcd中，各个组件通过api-server的接口进行访问etcd来获取资源信息，kube-proxy会作为daemon(守护进程）跑在每个节点上通过watch的方式监控着etcd中关于pod的最新状态信息，它一旦检查到一个pod资源被删除了或新建或ip变化了等一系列变动，它就立即将这些变动反应在iptables或ipvs规则中，以便之后再有请求发到service时，service可以通过ipvs最新的规则将请求分发到pod上。
kube-proxy 和service的关系：
kube-proxy负责制定数据包的转发策略，并以守护进程的模式对各个节点的pod信息实时监控并更新转发规则，service收到请求后会根据kube-proxy制定好的策略来进行请求的转发，从而实现负载均衡。
