k8s之神秘链条追踪

一、证人口供

        接到报警，某公司突然多出3个nginx服务器，尝试删除其中任意一个，都会自动生成一个新的，而且数量总是保持在3个，都快过年了，影响特别恶劣，着实另人苦脑 。证人说在公司其中一台节点服务器上发现了一个名叫deployment.yaml的可疑文件，内容如下：

二、事件分析

       经过多年的从业经验判断，该公司应该存在一个k8s集群，有人利用kubectl这个CLI工具，apply了一个deployment.yaml，通过HTTP POST请求发送到了k8s的api-server.启动了3个pod,每个pod里存在1个nginx容器。因为k8s的自我修复特性，直接用delete删除某个pod是徒劳的，k8s总是可以让pod副本数量达到渴望的3个。

三、明查暗访

        Kubernetes可以部署在云端、虚拟机、祼金属组成集群或联邦，每个集群由若干个master节点和若干个worker节点组成，请注意我使用若干个，用以说明k8s集群的高可用性。先说master节点有一个控制平面，它有api-server,controler-manager控制器管理器,scheduler调度器，etcd组成，其中api-server是这个控制平台的大脑，用来接收客户端的请求，并监控控制器管理器的状态，同时会把状态存储在etcd这个分存式键值数据库。控制器管理器是一个合集，由replicaset controler,deployment controler等各类控制器组成，各控制器各尽其职，做好自己本分，共同完成对应用的部署等工作。而调度器体现了k8s另一大特性，自我扩展性，调度器内部有自身的算法，可以准确计算pod部署到哪个工作节点最优。etcd存储着所有配置信息和状态信息，用相应的命令可以查到具体的值，这个以后我可能会单独讲。值得一提的是，这些组件本身也是pod，大多在k8s集群的kube-system命名空间里。接着说工作节点，工作节点由kubelet,容器引擎和具体的pod组成。kubelet负责与api-server互动，并通知容器引擎（通常是docker，因为docker已基本统冶了容器世界），而pod是k8s管理的最小单位，k8s并不直接管理容器，所有容器都封装在pod里，在这里要提一下虚拟化，虚拟化管理的最小单位是虚拟机，每个虚拟机都有自己的操作系统。而容器不是虚拟机，容器共享的是底层宿主机的操作系统，实现计算，存储，网络，进程之间的隔离，而且它比虚所机更轻量，便携。选择用容器替代臃肿的虚拟机来部署和管理应用，可以轻易实现高可用，同时节省成本。

四、结果公示

       回到证人找到的证据，那个yaml文件，当kubectl向api-server发出请求，api-server会先检查这个yaml是否合法，自上而下发出相应通知。kind里写的是Deployment，因此api-server会先通知deplolyment控制器，deployment控制器收到通知后开始部署工作，看到该文件里replica声明的是是3，因此会通知负责创建replica的replicaset控制器,replicaset控制器会按yaml要求创建3个pod,而pod跟着就会通知调度器，把自己需要的资源数，封装的容器信息告诉调度器，调度器根据自身算法，为pod分配合适的节点，这3个pod虽然封装的是同一个nginx容器镜像，但是并不一定要部署到同一个节点，从高可用角度来说这样也不安全，如果该节点故障，即使有3个副本，同样也是灾难性的。而调度器有许多高级调度能力，比如亲缘与反亲缘，污点与容忍度等，后面我可能也会分别介绍调度器的高级调度功能。继续分析这个链条，pod得知自己要分配到哪个节点后，会与该节点上的kubelet联系，kubelet收到通知立即给docker联系，docker就会用自己的容器运行时（docker的容器运行时是containerd），容器运行时最终启动容器。就是k8s部署，调度，运行容器化应用的整个过程。

五、后续总结

       此篇博文仅是为了说明k8s的基本概念和工作机制，也只有对这些有一个初步的概念，后续才可以和大家继续大话kubernetes。若不讲这些，kubernetes的部署，运维，排错，自定义资源的方法，k8s与AI的结合，knative,openshift等等都无从谈起。比如此文里说的证据yaml文件如何书写规范，有哪些书写技巧等，笔者接下来会专门写一篇文章。