登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发技术 > 正文

为什么 kubernetes 天然就适合微服务?

2018-05-25 10:20    来源:刘超的通俗云计算  作者: 刘超 编辑: 田晓旭

  【IT168 技术】最近总在思考,为什么在支撑容器平台和微服务的竞争中,Kubernetes 会取得最终的胜出,事实上从很多角度出发三大容器平台从功能方面来看,最后简直是一摸一样。

  经过一段时间的思索,以及采访了从早期就开始实践 Kubernetes 的网易云架构师们后,我把反思所得总结为今天的这篇文章。

  一、从企业上云的三大架构看容器平台的三种视角

  一切都从企业上云的三大架构开始看起

为什么 kubernetes 天然就适合微服务?

  如图所示,企业上云的三大架构为 IT 架构、应用架构和数据架构,在不同的公司,不同的人、不同的角色,关注的重点不同。

  对大部分的企业来讲,上云的诉求是从 IT 部门发起的,发起人往往是运维部门,他们关注计算、网络、存储,试图通过云计算服务来减轻 CAPEX 和 OPEX。

  有的公司有 ToC 的业务,因而累积了大量的用户数据,公司的运营需要通过这部分数据进行大数据分析和数字化运营,因而在这些企业里面往往还需要关注数据架构。

  从事互联网应用的企业,往往首先关注的是应用架构,是否能够满足终端客户的需求,带给客户良好的用户体验。业务量上往往会有短期内出现爆炸式增长的现象,因而关注高并发应用架构,并希望这个架构可以快速迭代,从而抢占风口。

  在容器出现之前,这三种架构往往通过虚拟机云平台的方式解决。当容器出现之后,容器的各种良好的特性让人眼前一亮,它的轻量级、封装、标准、易迁移、易交付的特性,使得容器技术迅速被广泛使用。

为什么 kubernetes 天然就适合微服务?

  然而一千个人心中有一千个哈姆雷特,由于原来工作的关系,三类角色分别从自身的角度看到了容器的优势给自己带来的便捷。

  对于原来在机房里管计算、网络、存储的 IT 运维工程师来讲,容器更像是一种轻量级的运维模式,在他们看来,容器和虚拟机的最大的区别就是轻量级,启动速度快,他们往往更愿意推出虚拟机模式的容器。

  对于数据架构来讲,他们每天都在执行各种各样的数据计算任务,容器相对于原来的 JVM,是一种隔离性较好,资源利用率高的任务执行模式。

  从应用架构的角度出发,容器是微服务的交付形式,容器不仅仅是做部署的,而且是做交付的,CI/CD 中的 D 的。

  所以这三种视角的人,在使用容器和选择容器平台时方法会不一样。

  二、Kubernetes 才是微服务和 DevOps 的桥梁

  Swarm:IT 运维工程师

  从 IT 运维工程师的角度来看:容器主要是轻量级、启动快,并且自动重启,自动关联,弹性伸缩的技术,使得 IT 运维工程师似乎不用再加班。

  Swarm 的设计显然更加符合传统 IT 工程师的管理模式。

  他们希望能够清晰地看到容器在不同机器的分布和状态,可以根据需要很方便地 SSH 到一个容器里面去查看情况。

  容器最好能够原地重启,而非随机调度一个新的容器,这样原来在容器里面安装的一切都是有的。

  可以很方便地将某个运行的容器打一个镜像,而非从 Dockerfile 开始,这样以后启动就可以复用在这个容器里面手动做的 100 项工作。

  容器平台的集成性要好,用这个平台本来是为了简化运维的,如果容器平台本身就很复杂,像 Kubernetes 这种本身就这么多进程,还需要考虑它的高可用和运维成本,这个不划算,一点都没有比原来省事,而且成本还提高了。

  最好薄薄的一层,像一个云管理平台一样,只不过更加方便做跨云管理,毕竟容器镜像很容易跨云迁移。

  Swarm 的使用方式比较让 IT 工程师有熟悉的味道,其实 OpenStack 所做的事情它都能做,速度还快。

为什么 kubernetes 天然就适合微服务?

  Swarm 的问题

  然而容器作为轻量级虚拟机,暴露出去给客户使用,无论是外部客户,还是公司内的开发,而非 IT 人员自己使用的时候,他们以为和虚拟机一样,但是发现了不一样的部分,就会有很多的抱怨。

  例如自修复功能,重启之后,原来 SSH 进去手动安装的软件不见了,甚至放在硬盘上的文件也不见了,而且应用没有放在 Entrypoint 里面自动启动,自修复之后进程没有跑起来,还需要手动进去启动进程,客户会抱怨你这个自修复功能有啥用?

  例如有的用户会 ps 一下,发现有个进程他不认识,于是直接 kill 掉了,结果是 Entrypoint 的进程,整个容器直接就挂了,客户抱怨你们的容器太不稳定,老是挂。

  容器自动调度的时候,IP 是不保持的,所以往往重启后原来的 IP 就没了,很多用户会提需求,这个能不能保持啊,原来配置文件里面都配置的这个 IP ,挂了重启就变了,这个怎么用啊,还不如用虚拟机,至少没那么容易挂。

  容器的系统盘,也即操作系统的那个盘往往大小是固定的,虽然前期可以配置,后期很难改变,而且没办法每个用户可以选择系统盘的大小。有的用户会抱怨,我们原来本来就很多东西直接放在系统盘的,这个都不能调整,叫什么云计算的弹性啊。

  如果给客户说容器挂载数据盘,容器都启动起来了,有的客户想像云主机一样,再挂载一个盘,容器比较难做到,也会被客户骂。

  如果容器的使用者不知道他们在用容器,当虚拟机来用,他们会觉得很难用,这个平台一点都不好。

  Swarm 上手虽然相对比较容易,但是当出现问题的时候,作为运维容器平台的人,会发现问题比较难解决。

  Swarm 内置的功能太多,都耦合在了一起,一旦出现错误,不容易 debug。如果当前的功能不能满足需求,很难定制化。很多功能都是耦合在 Manager 里面的,对 Manager 的操作和重启影响面太大。

  Mesos:数据运维工程师

为什么 kubernetes 天然就适合微服务?

  从大数据平台运维的角度来讲,如何更快地调度大数据处理任务,在有限的时间和空间里面,更快地跑更多的任务,是一个非常重要的要素。

  所以当我们评估大数据平台牛不牛的时候,往往以单位时间内跑的任务数目以及能够处理的数据量来衡量。

  从数据运维的角度来讲,Mesos 是一个很好的调度器。既然能够跑任务,也就能够跑容器,Spark 和 Mesos 天然的集成,有了容器之后,可以用更加细粒度的任务执行方式。

  在没有细粒度的任务调度之前,任务的执行过程是这样的。任务的执行需要 Master 的节点来管理整个任务的执行过程,需要 Worker 节点来执行一个个子任务。在整个总任务的一开始,就分配好 Master 和所有的 Work 所占用的资源,将环境配置好,等在那里执行子任务,没有子任务执行的时候,这个环境的资源都是预留在那里的,显然不是每个 Work 总是全部跑满的,存在很多的资源浪费。

  在细粒度的模式下,在整个总任务开始的时候,只会为 Master 分配好资源,不给 Worker 分配任何的资源,当需要执行一个子任务的时候,Master 才临时向 Mesos 申请资源,环境没有准备好怎么办?好在有 Docker,启动一个 Docker,环境就都有了,在里面跑子任务。在没有任务的时候,所有节点上的资源都是可被其他任务使用的,大大提升了资源利用效率。

  这就是 Mesos 最大的优势,在 Mesos 的论文中,最重要阐述的就是资源利用率的提升,而 Mesos 的双层调度算法是核心。

  号称了解mesos双层调度的你,先来回答下面这五个问题!

  原来大数据运维工程师出身的,会比较容易选择 Mesos 作为容器管理平台。不过原来是跑短任务,加上 marathon 就能跑长任务。但是后来 Spark 将细粒度的模式 deprecated 掉了,因为效率还是比较差。

  Mesos 的问题

为什么 kubernetes 天然就适合微服务?

  调度在大数据领域是核心中的核心,在容器平台中是重要的,但不是全部。所以容器还需要编排,需要各种外围组件,让容器跑起来运行长任务,并且相互访问。Marathon 只是万里长征的第一步。

  所以早期用 Marathon + Mesos 的厂商,多是裸用 Marathon 和 Mesos 的,由于周边不全,因而要做各种的封装,各家不同。大家有兴趣可以到社区上去看裸用 Marathon 和 Mesos 的厂商,各有各的负载均衡方案,各有各的服务发现方案。

  所以后来有了 DCOS,也就是在 Marathon 和 Mesos 之外,加了大量的周边组件,补充一个容器平台应有的功能,但是很可惜,很多厂商都自己定制过了,还是裸用 Marathon 和 Mesos 的比较多。

  而且 Mesos 虽然调度牛,但是只解决一部分调度,另一部分靠用户自己写 framework 以及里面的调度,有时候还需要开发 Executor,这个开发起来还是很复杂的,学习成本也比较高。

  虽说后来的 DCOS 功能也比较全了,但是感觉没有如 Kubernetes 一样使用统一的语言,而是采取大杂烩的方式。在 DCOS 的整个生态中,Marathon 是 Scala 写的,Mesos 是 C++ 写的,Admin Router 是 Nginx+lua,Mesos-DNS 是Go,Marathon-lb 是 Python,Minuteman 是 Erlang,这样太复杂了吧,林林总总,出现了 Bug 的话,比较难自己修复。

  Kubernetes

为什么 kubernetes 天然就适合微服务?

  而 Kubernetes 不同,初看 Kubernetes 的人觉得他是个奇葩所在,容器还没创建出来,概念先来一大堆,文档先读一大把,编排文件也复杂,组件也多,让很多人望而却步。我就想创建一个容器,怎么这么多的前置条件。如果你将 Kubernetes 的概念放在界面上,让客户去创建容器,一定会被客户骂。

  在开发人员角度,使用 Kubernetes 绝对不是像使用虚拟机一样,开发除了写代码,做构建,做测试,还需要知道自己的应用是跑在容器上的,而不是当甩手掌柜。开发人员需要知道,容器是和原来的部署方式不一样的存在,你需要区分有状态和无状态,容器挂了起来,就会按照镜像还原了。开发人员需要写 Dockerfile,需要关心环境的交付,需要了解太多原来不了解的东西。实话实说,一点都不方便。

  在运维人员角度,使用 Kubernetes 也绝对不是像运维虚拟机一样,我交付出来了环境,应用之间互相怎么调用,我才不管,我就管网络通不通。在运维眼中他做了过多不该关心的事情,例如服务的发现,配置中心,熔断降级,这都应该是代码层面关心的事情,应该是 SpringCloud 和 Dubbo 关心的事情,为什么要到容器平台层来关心这个。

  Kubernetes + Docker,却是 Dev 和 Ops 融合的一个桥梁。

  Docker 是微服务的交付工具,微服务之后,服务太多了,单靠运维根本管不过来,而且很容易出错,这就需要研发开始关心环境交付这件事情。例如配置改了什么,创建了哪些目录,如何配置权限,只有开发最清楚,这些信息很难通过文档的方式又及时又准确地同步到运维部门来,就算是同步过来了,运维部门的维护量也非常的大。

  所以,有了容器,最大的改变是环境交付的提前,是每个开发多花 5% 的时间,去换取运维 200% 的劳动,并且提高稳定性。

  而另一方面,本来运维只管交付资源,给你个虚拟机,虚拟机里面的应用如何相互访问我不管,你们爱咋地咋地,有了 Kubernetes 以后,运维层要关注服务发现,配置中心,熔断降级。

  两者融合在了一起。在微服务化的研发的角度来讲,Kubernetes 虽然复杂,但是设计的都是有道理的,符合微服务的思想。

 

标签: Kubernetes
相关文章
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫码送文库金币

编辑推荐
系统架构师大会
系统架构师大会
点击或扫描关注
IT168企业级微信关注送礼
IT168企业级微信关注送礼
扫描关注
首页 评论 返回顶部