[Kubernetes]谈谈Kubernetes的本质

怼烎@ 2022-03-26 01:18 180阅读 0赞

当下k8s算是比较火的一个内容,那么它到底是什么呢,它为什么会这么火呢,它解决的是什么问题呢.这篇文章就尝试着来讲讲,Kubernetes的本质.

当我们谈Kubernetes的时候,总是会想起来Docker.是的,如果想要知道Kubernetes解决的是什么问题,我们不可避免的再回到Docker上面,回到容器上面来.  
在"开发-测试-发布"的流程中,真正承载着容器信息进行传递的,是容器镜像.所以,当Docker项目成功后不久,它就迅速走向"容器编排"的重要原因:作为一家云服务商或者基础设施提供商,我只要能够将用户提交的Docker镜像以容器的方式运行起来,就能成为容器生态圈上的一个承载点,从而将整个容器技术栈上的价值,沉淀在我的这个节点上.此外,只要从我这个承载点向Docker镜像制作者和使用者方向回溯,整条路径上的各个服务节点,比如监控,安全,网络,存储等等,都有可以发挥和盈利的地方.所以,这也是为什么云计算提供商如此热衷于容器技术的重要原因:我可以通过容器镜像,和潜在用户(开发者)直接关联起来.  
基于以上,容器从一个开发者手里的小工具,一跃成为了云计算领域的绝对主角;而能够定义容器组织和管理规范的"容器编排"技术,则当仁不让的成为了当下最火热的技术.

那么,Kubernetes要解决的问题是什么?编排?调度?还是集群管理?  
这个问题,到现在也没有固定的答案,因为在不同的发展阶段,Kubernetes需要着重解决的问题是不同的.对于大多数用户来说,有一点是确定的:现在我有了应用的容器镜像,请帮我在一个给定的集群上把这个应用运行起来.更进一步说,我现在有了一个能够应用的容器镜像,那么我还希望Kubernetes能够给我提供路由网关,监控,备份等一系列运维能力.  
说到这里,我们就需要来讲讲Kubernetes的架构了.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70]  
从上图中我们能够看到,Kubernetes项目的架构,由Master和Node两种节点组成.Master节点(即控制节点),由三个紧密协作的独立组件组合而成,它们分别是负责API服务的kube-apiserver,负责调度的kube-scheduler,以及负责容器编排的kube-controllermanager.而整个集群的持久化数据,则由kube-apiserver处理后保存在Etcd中.  
计算节点上最核心的部分,是一个叫做kubelet的组件.在Kubernetes项目中,kubelet主要负责同容器运行时(比如Docker项目)打交道.而这个交互所依赖的,是一个称作CRI(Container Runtime Interface)的远程调用接口,这个接口定义了容器运行时的各项核心操作.这也是为什么,Kubernetes项目并不关心你部署的是什么容器运行时,使用的什么技术实现,只要你的容器运行时能够运行标准的容器镜像,它就可以通过实现CRI接入到Kubernetes项目当中.  
正是因为如此,Kubernetes项目没有像同时期的各种"容器云"项目那样,把Docker作为整个架构的核心,而仅仅把它作为最底层的一个容器运行时实现.  
运行在大规模集群中的各种任务之间,实际上存在着各种各样的关系,这些关系的处理,才是作业编排和管理系统最困难的地方.而这也是Kubernetes项目要着重解决的问题.

Kubernetes着重解决的问题,也比较好理解.在容器技术普及之前,传统虚拟机环境对各种关系的处理方法都是比较"粗粒度"的.如果你善于发现,你会经常看到很多功能并不相关的应用被一股脑儿的部署在同一台虚拟机中,只是因为它们之间偶尔会互相发起几个HTTP请求.更常见的情况就是,当一个应用被部署在虚拟机里之后,你还需要手动维护很多跟它协作的守护进程,用来处理它的日志搜集,灾难恢复等辅助工作.  
但当容器技术出现后,你会发现,在"功能单位"的划分上,容器有着独一无二的"细粒度"的优势:因为容器的本质,只是一个进程而已.  
这样的意思就是说,只要你愿意,那些原来拥挤在同一个虚拟机里的各个应用,组件,守护进程,都可以被分别做成镜像,然后运行在一个个专属容器中.它们之间互不干涉,拥有各自的资源配额,可以被调度在整个集群里的任何一台机器上.这也是"微服务"思想能够落地的前提条件.

在上文中说了,Kubernetes项目着重要处理的问题是,对于各种关系的处理.先来一张Kubernetes项目核心功能的"全景图":  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 1]  
在这幅图中,我们从容器这个最基础的概念触发,首先遇到了容器间"紧密协作"关系的难题,于是就扩展到了Pod;有了Pod之后,我们希望能一次启动多个应用的实例,此时就需要Deployment这个Pod的多实例管理器;而有了这样一组相同的Pod后,我们又需要通过一个固定的IP地址和端口以负载均衡的方式访问它,于是就有了Service.

讲了这么多,那么Kubernetes的本质是什么呢?它的本质是为用户提供一个具有普遍意义的容器编排工具.如果非要一个很形象的比喻的话,你可以把它理解为操作系统.  
过去很多集群管理项目所擅长的都是把一个容器,按照某种规则,放置在某个最佳节点上运行起来,这种功能我们称为"调度".但Kubernetes项目所擅长的,是按照用户的意愿和整个系统的规则,完全自动化处理好容器之间的各种关系,这种功能,叫做编排.  
但是Kubernetes为用户提供的不仅限于一个工具,它真正的价值,在于提供了一套基于容器构建分布式系统的基础依赖.

最后,上一张导图吧,算是对以上内容的一个总结(是不是看到导图就觉得好理解一些):  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 2]以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.  
感谢您的阅读~

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70]: /images/20220326/86b4c44a5bfe4411b2d50e54d76534d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 1]: /images/20220326/4e3eda10c551432b9f00f95a0a662c8a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70 2]: /images/20220326/b87f5580e0cf43239a29398f9bb3fb40.png