K8S技术庞杂，内容繁多，密度量大，如果一头扎进官网文档，估计会犯晕。这里提炼概览，对核心概念和流程进行分析讲解，在脑海里重建Master和Worker节点和他们的组件构成。最后通过一个发布样例，展示这些组件是如何配合工作的。最后展示K8S的总体架构

　　两大角色

　　

　　K8S有两大角色，一个是Master节点，一个是Worker节点。

　　其中Master负责管理和调度集群资源，Worker负责提供集群资源。

　　在一个高可用的集群当中，他俩一般由多个节点构成，这些节点可以是虚拟机也可以是物理机。

　　Worker提供的节点叫Pod，简单理解Pod就是K8S云平台提供的虚拟机，Pod里头住的是应用容器，比如Docker容器。

　　大部分情况Pod里只包含一个容器；有时候也包含多个容器，其中一个是主容器，其他是辅助容器。

　　为了加深理解，这里做个简单类比。Master好比指挥调度员工干活的主管，Worker好比部门当中实际干活的人。

　　K8S主要解决集群资源调度的问题，当有应用发布请求过来的时候，K8S会根据集群资源的空闲状态，把集群当中空闲的Pod合理的分配到Worker当中；另外，K8S还负责监控集群，当集群中有节点或者Pod挂了，它需要重新协调和启动Pod，保证应用的高可用，这个技术也叫自愈；另外K8S还需要管理集群的网络，保证Pod和服务之间可以互通互联。

　　Master节点和构成

　　

　　Master节点是集群的大脑，它由四大组件构成：

　　etcdetcd是分布式的KV数据库，负责状态存储，所有集群的状态，比如节点Pod发布，配置等等。高可用的etcd集群部署一般要三个节点。etcd可以独立部署，也可以和Master节点一起部署。api server集群的接口和通信总线。kubectl，kubelet，kube-proxy，dashboard，sdk操作背后都是通过api server和集群进行交互。可以理解为etcd的一个代理，是唯一能够直接访问和操作etcd的组件，其他QQ账号出售平台组件都只能依赖api server间接操作etcd。它还是集群的事件总线(EventBus)，其他组件可以订阅它，当有事件发生时候，会通知感兴趣的这些组件。

　　

　　scheduler负责集群调度决策。当新的应用请求到达集群，scheduler负责决策相应的Pod应该分布到哪些空闲节点上。controller manager负责保证集群状态最终一致性。它通过api server监控集群的最终状态，确保集群状态和预期状态是一致的。如果一个运用要求发布10个Pod，controller manager会最终启动10个Pod，如果一个Pod挂了，它会负责协调，重新启动Pod。如果Pod启多了，它会协调关闭多余Pod。也就是说，K8S采用的是最终一致调度策略，它是集群自愈背后的实现机制。Worker节点和构成

　　worker节点是集群资源的提供者，它由这几个组件构成：

　　

　　kubelet向下，它是worker节点的资源管理者，相当于一个agent，它并不是直接管理节点资源，而是委托container runtime进行管理。比如启动、关闭容器、收集容器状态。向上，它负责监听api server产生的事件，根据master的指示，启动或关闭Pod等资源；它也负责将本节点上的状态汇报给master节点。如果说master节点是K8S集群的大脑，那么kubelet节点则是worker节点的小脑。container runtime是节点容器资源的直接管理者。如果采用docker容器，管理的就是docker引擎。如果本地没有镜像缓存，它会到docker register或者docker hub上拉取相依的镜像，然后缓存在本地。kube-proxy 负责管理K8S集群上的服务组件。我们知道Pod是K8S当中一个不固定的概念，为了屏蔽PodIP的变化(包括预期和非预期变化)，K8S引入Server组件，并且在调用的时候进行负载均衡。kube-proxy就是实现k8s server背后机制。另外，当需要把K8S当中的服务暴露给外网的时候，也是通过kube0-proxy进行代理转发。 发布流程

　　接下来通过一个发布流程展示这些组件之间是如何配合工作的。

　　

　　向api server发送create new replicaset请求，api server会把请求存储在etcd当中。controller manager会监听到replicset的创建或修改相关事件。controller manager接收到通知，会比较当前集群状态和预知集群状态，它发现不一致，需要创建新的Pods。你通过kubectl提交的发布模板，在api server当中创建预期的Podscheduler监听到需要创建新的Pod资源，它通过调度算法，选择空闲节点，然后跟进api server更新Pod的定义，这个定义将Pod分配到指定的节点上。注意到这一步，应用还没真正发布，controller manager和scheduler只是通过api server更新了预期的集群状态。一旦Pod被指定分配给某个workder节点，api server就会通知相应节点上的kubelet。kubelet接收到通知，就会指示节点上的container runtime，比如说docker engine运行相应的容器。container runtime开始下载镜像，启动容器。kubelet也开始监控容器的运行，到这一步应用容器就开始正式运行了。 综合架构

　　前面对K8S的组件分别进行了分析，接下来我们综合起来看一下它的总体架构。

　　

　　集群中的Pod通过overlay network相互寻址和通信。实现覆盖网络的技术很多，比如Flannel，Vxlen，Callco，Weave-Net。

　　另外如果外网流量要访问集群当中的服务，一般要走负载均衡器（Load Balander），再通过kube-proxy间接地转发到服务的Pod上。

　　除了前面这些组件，外围还包括存储，监控，日志，分析等配套的支撑服务。

　　对于K8S这种复杂而庞大的系统，我们先要了解它的架构，包括组件的构成和作用，流程，总体架构。帮助我们在头脑当中建立起K8S的架构概念模型，帮助我们在实践中学习和运用好K8S。