K8S背景

ronald10个月前职场2110

    在深入了解K8S之前,我们先了解一下K8S产生的背景,看下是为了解决怎样的问题一步步衍生出K8S这样一套系统。

一. 微服务化

    随着需求的发展,单体应用的复杂度越来越高,大大增加了系统现网的运维成本,主要包括以下几个方面

    1. 模块耦合度提升,维护成本高    

    当单体应用承载的功能越来越多,应用内模块增多,各个模块之间关联度的增加:

    首先是原有模块的升级,由于模块间存在复杂的关联,入口多且复杂,在对原有模块升级时需要考虑该模块接口的改动对于其他模块的影响,大大增加模块升级的风险和开发成本;

    其次,单体应用继承的模块越来越多,实际现网运营过程中,我们可能只需要对其中一个模块进行发布和升级,但是这种强绑定的方式导致我们对任一模块的升级会迫使其他模块也跟着暂停服务,增大了发布的影响也不利于收敛发布风险;

    最后,对于这样的功能集成方式,在遇到新模块开发时,不仅需要考虑新老模块在接口的兼容度的问题,还可能存在单体应用的不同模块库依赖的版本冲突问题,导致新增模块开发工作量提升。

    2. 计算复杂,单应用计算量增加,机器成本增加

    随着单应用集成模块的增加,应用承载的运算越来越复杂且多样,导致我们的应用对于机器性能的要求越来越高,从而导致我们的机器成本增加。

    3. 扩容成本增加

        设想,我们的应用有A、B、C三个模块,上线之后,由于B模块过载使得整个应用成为系统的瓶颈,此时实际上我们只需要对B模块执行扩容操作,但由于这种绑定机制我们只能将A、B、C绑定进行扩容;一方面由于A和C模块占用了B模块的算力,使得我们需要加更多的机器,导致我们扩容成本增加;另一方面,由于A和C本来就不是热点,也必须跟着进行扩容,进一步导致A、C模块的资源利用率的降低,这块算力就被浪费了。

    基于上述的种种,微服务化的理念被倡导以及广泛应用,简单来说,微服务化就是将应用充分解耦,将里面各个模块高度拆分到各个进程中,每个进程只专注于一个功能,且对外通过网络对系统内其他模块提供服务。这种微服务化的部署机制,使得模块之间充分解耦互不干扰,各个模块以进程组的形式提供服务,当单点遇到瓶颈时,只需要对指定模块进行扩容即可,不需要因为原来的绑定关系付出额外的扩容成本,同时,由于各个进程的功能聚焦且单一,因此各模块对于机器的部署要求也大大降低。

二. 容器化

    看着微服务化是解决应用膨胀带来一系列问题的银弹,但实际在应用过程中,又发现了其他新的问题:因为应用拆分的越来越细,实际每个进程部署所需的机器环境、依赖库的信息、环境变量等变得非常的个性且差异化,此外,运维还得关注业务进程的系统资源如端口信息、文件信息等的配置不能产生冲突;这些差异化的配置琐碎且复杂;此外不仅在部署阶段需要关注这些信息,节点故障替换、扩容、机器升级等高风险的现网操作都得关注这些信息,这显然是项目团队不愿意看到的;理想中的发布模型中,运维不需要关注这些依赖库、环境变量的差异化,且进程的运行环境是干净的,不用担心存在系统资源的冲突,这就是容器化要解决的问题:

    容器化的发布机制中,各个进程以镜像形式进行打包发布,镜像中不仅含有进程运行所需的可执行文件,还包括相关的依赖库和环境变量,这些对于运维完全无感知,此外进程运行在容器中,一个“看似”独占的机器环境,也不需要运维进行任何差异化的配置。

三. 容器编排化

    通过镜像打包发布以及容器化的运行方式,我们的运维不用再去担心进程间的配置冲突、也不用为不同的机器安装各种库、设置各种环境变量等,但运维还是无法完全回避对于业务的理解:

        设想场景一:对于有些IO密集型服务,我们希望进程调度到装有SSD磁盘的机器上,是否我们的运维需要去关注机器差异性和对应容器的匹配?

        设想场景二:若是我们部分业务,需要借助GPU的算力,是否我们运维也需要关注哪些容器是需要GPU的,而哪些节点又安装有GPU?

        设想场景三:对于有些互联网业务,如全球部署的游戏业务,我们希望能做到战局服务器的就近部署以达到就近接入的目的,那是否我们的运维也得关注节点的部署信息和项目的发布需求?

    除此之外,在实际现网运维过程中,我们希望现网的运维系统更加的通用和健壮,能做到自动的故障发现、容灾容错、扩容缩容...这就是容器编排的意义所在;通过容器编排系统,不仅可以做到容器和节点的自动适配,还可以实现自动的故障发现、故障节点的自动替换,以及自动的扩容缩容(当然我们可以在业务层自己做,但是容器编排系统已经帮我们都做好了,我们只需要在需要地方进行配置和少量的编程即可),而K8S就是使用最广泛的一类容器编排系统。

参考资料

    https://www.qikqiak.com/k8strain/k8s-basic/pod/

    http://docs.kubernetes.org.cn/683.html:kubectl命名表

    https://www.cnblogs.com/gdut1425/p/13046507.html:PV和PVC原理

    https://blog.csdn.net/qq_36807862/article/details/106068871:iptables vs ipvs

    http://dockone.io/article/4884:nodeport、ingress、loadbalance


标签: K8S

相关文章

K8S入门-概念篇(上)

K8S入门-概念篇(上)

    认识到K8S的产生背景之后,我们开始进一步了解K8S,基于对K8S里面一些概念的了解之后,我们再去探讨K8S的一些原理:一. node    如前所述,K8S是一个容器编排平台,即容器的自动部署、扩展和管理;其最终的落点是把容器调度到一个运行他的节点上,在K8S中这个运行容器的节点就是node,但是需要注意的是...

K8S入门-概念篇(下)

K8S入门-概念篇(下)

一. volume    volume解决的是pod上不同容器之间共享文件的问题和容器文件持久化的问题;K8S提供了以下几类volume:1. hostPath    hostPath是一种通过pod所在node上的文件系统指定的文件或者目录实现文件共享,如下所示,先在Pod内定义一个volume,类型定义为hostP...

K8S入门-原理篇

K8S入门-原理篇

一. K8S总体架构及组件功能    K8S总体架构图如下所示:    在K8S中,整个集群划分为控制节点和工作节点,其中控制节点分为:    ·ETCD        一个分布式的数据库,用于存储集...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。