Docker和k8s作为近些年来兴起的容器技术代表，已经被越来越多的公司作为服务运维的方式。但是作为一名爱技术的程序员，对于k8s的理解仅仅停留在会模仿写一下cm、service和deployment这几个yml文件，那是远远不够的。今天从一条命令kubectl run nginx --image=nginx出发，给大家分享一下k8s的构成组件。
故事的开篇从官网的一张图开始，作为k8s组件的总览。后面会根据kubectl命令的执行依次说明每个组件的作用。
整个图分为三大部分：1、Control Plane；2、Node；3、Cloud provider API
其中，Control Plane包含：kube-apiserver（api）、etcd、kube-scheduler（sched）、kube-controller-manager（c-m）、cloud-controller-manager（c-c-m），Node里包括：kubelet、kube-proxy。
在讲kubectl命令在k8s集群流转链路前，我们首先需要知道k8s集群中的每台机器叫做Node,而Node分为两大类：一个是Master，一个是Worker。虽然没有强制说明Master机器上不能运行Pod，但是在k8s官网中不建议我们这样做。
Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all control plane components on the same machine, and do not run user containers on this machine.
翻译：Control Plane组件可以在群集中的任何机器上运行。但是，为了简单起见，启动脚本通常在同一台机器上启动所有Control Plane组件，并且不在此机器上运行用户容器。
下面，我们从kubectl run nginx --image=nginx这条命令出发，看看到底发生了什么。
首先，用户在shell中敲出这段命令并回车，kubectl客户端会将这条命令封装成一个HTTP请求，发到Control Plane中的kube-apiserver组件，这个组件你可以理解为整个k8s集群的入口，任何外部的操作请求都需要经过它。kube-apiserver在收到这个请求后，首先会对其进行参数以及合法性校验，比如语句语法是否正确、请求命令希望操作的资源是否合法等。在校验通过后，会将这条命令存储到Control Plane里的另一个重要组件etcd中。
一旦存储到etcd，那么就会被Control Plane里的kube-controller-manager组件检测到，这个组件的作用主要是针对etcd中的命令内容，开始构建指定的资源，比如构建deployment、replicaSet等，资源构建完成后，将相关信息更新到etcd中。但是请注意，到这里只是构建资源，还并没有真正的运行nginx这个pod，或者说，还早得很！！！
当kube-controller-manager将对应资源构建完成，并更新到etcd后，Control plane里的另一个组件kube-scheduler就派上用场。他同样会检测到etcd中的变更，根据变更信息开始执行调度，比如将服务部署到哪个Node。对于Node的选择，kube-scheduler有一套自己的策略，这里不做深究，总之它能够根据你的命令，选择到合适的Node，将服务调度到对应的Node。调度完成的标志依然是更新NodeName到etcd中，可能大家也注意到了，其实在这一步，服务依然没有在Worker Node上启动，依然是etcd的更新操作，容器处于pending状态！
那么Worker Node是怎么感知到我这个Node上需要启动一个Pod的呢？
这就需要Node里的kubelet组件登场了！！！它会检测到etcd中关于自身Node的信息，并对Node上已经存在的容器进行对比，发现差异后执行对应的操作，到这一步才真正的在Node上启动了Pod！！！
大功告成！！！
