# **一、Kubernetes架构概览**  ***** 上图为Kubernetes的架构的概览。在Kubernetes集群中主要由两类角色，分别为：Master节点和Worker节点；简单来说，Master节点主要用来管理和调度集群资源的，而Worker节点则是提供资源（运行实际的业务服务的）；在一个高可用Kubernetes集群中，Master和Worker节点都需要由多个节点构成。这些节点可以是物理机，也可以是虚拟机，也可以直接是云主机 ***** Worker节点提供的资源单位称为Pod，简单来说，Pod就是Kubernetes云平台提供的虚拟机。Pod是Kubernetes调度的最小单位，在Pod里可以运行单个容器或者多个容器。 一个Pod里面的多个容器共享存储资源和网络资源 ***** Kubernetes主要解决集群资源调度的问题，简单来说，就是Kubernetes需要根据集群服务器的资源空闲现状，将我们的应用服务分配到空闲的Worker节点上。同时，Kubernetes也需要监控集群的状态，当有节点或者Pod挂掉，它要能够重新协调和启动Pods，保证应用高可用，另外，Kubernetes需要管理集群网络，保证Pod/服务之间可以互通互联 ***** #### **二、Master/Worker节点组件构成**  **Master节点是Kubernetes集群大脑，它由如下组件构成：** 1、Etcd： 它是Kubernetes的集中状态存储，所有的集群状态数据，例如节点，Pods，发布，配置等等，最终都存储在Etcd中。Etcd是一个分布式KV数据库，采用Raft分布式一致性算法。Etcd高可用部署一般需要至少三个节点。Etcd集群可以独立部署，也可以和Master节点住在一起。 2、API Server： 它是Kubenretes集群的接口和通讯总线。用户通过kubectl，dashboard或者sdk等方式操作Kubenretes，其背后通过API server和集群进行交互。并且集群内的其它组件，例如Kubelet/Kube-Proxy/Scheduler/Controller-Manager等，都通过API server和集群进行交互。API Server是唯一能够访问操作Etcd数据库的组件，其它组件，都必须通过API server间接操作Etcd。API server不仅接受其它组件的API请求，它还是集群的事件总线，其它组件可以订阅在API server上，当有新事件发生时候，API server会将相关事件通知到感兴趣的组件。 3、Scheduler：它是Kubenretes集群负责调度决策的组件。Scheduler掌握当前的集群资源使用情况，当有新的应用发布请求被提交到Kubenretes集群，它负责决策相应的Pods应该分布到哪些空闲节点上去。Kubenretes中的调度决策算法是可以扩展的。 4、Controller Manager：它是保证集群状态最终一致的组件。它通过API server监控集群状态，确保实际状态和预期状态最终一致，如果一个应用要求发布十个Pods，Controller Manager保证这个应用最终启动十个Pods，如果中间有Pods挂了，Controller Manager会负责协调重启Pods，如果Pods启多了，Controller Manager会负责协调关闭多余Pods。也即是说，Kubenretes采用最终一致调度策略，它是集群自愈的背后实现机制。  **Worker节点是K8s集群资源的提供者，它由如下组件构成：** 1、Kubelet： 它是Worker节点资源的管理者，相当于一个Agent角色。它监听API server的事件，根据Master节点的指示启动或者关闭Pod等资源，也将本节点状态数据汇报给Master节点。如果说Master节点是Kubenretes集群的大脑，那么Kubelet就是Worker节点的小脑 2、Container Runtime: 它是节点容器资源的管理者，如果采用Docker容器，那么它就是Docker Engine。Kubelet并不直接管理节点的容器资源，它委托Container Runtime进行管理，比如启动或者关闭容器，收集容器状态等。Container Runtime在启动容器时，如果本地没有镜像缓存，则需要到Docker Registry(或Docker Hub)去拉取相应镜像，然后缓存本地 3、Kube-Proxy： 它是管理Kubernetes中的服务(Service)网络的组件，Pod在Kubernetes是不固定的，PodIP可能会变(包括预期和非预期的)。为了屏蔽PodIP的可能的变化，Kubenretes中引入了Service概念，它可以屏蔽应用的PodIP，并且在调用时进行负载均衡。Kube-Proxy是实现Kubenretes服务(Service)网络的背后机制。另外，当需要把Kubenretes中的服务(Service)暴露给外网时，也需要通过Kube-Proxy进行代理转发。 ***** #### **三、流程样例**  下面我们通过一个发布流程，展示上面介绍的这些组件是如何配合工作的： 1、要发布一个新应用，他通过Kubectl命令行工具将发布请求提交到API server，API server将请求存储到Etcd数据库中 2、Scheduler通过API server监听到有新的应用发布请求，它通过调度算法决策，选择若干可发布的空闲节点，并将发布决策更新到API server 3、被选中的Worker节点上的Kubelet通过API server监听到有给自己的新发布任务,它根据任务指示在本地启动相应的Pods(间接通过Container Runtime启动容器)，并将任务执行成功情况报告给API server 4、所有Worker节点上Kube-Proxy通过API server监听到有新的发布，它获取应用的PodIP/ClusterIP/端口等相关数据，更新本地的iptables表规则，让本地的Pods可以通过iptables转发方式，访问到新发布应用的Pods 5、Controller Manager通过API server，时刻监控新发应用的健康状况，保证实际状态和预期状态最终一致 ***** #### **四、Kuberneter总体架构**  除了上述组件，K8s外围一般还有存储，监控，日志和分析等配套支持服务