欢迎光临
我们一直在努力

优乐综合社区为什么 kubernetes 天然适合微服务 (1)

此文已由作者刘超授权网易云社区发布。

欢迎访问网易云社区,了解更多网易技术产品运营经验

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

参考

Docker, Kubernetes, DCOS 不谈信仰谈技术

容器平台选型的十大模式:Docker、DC/OS、K8S谁与当先?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Swarm:IT 运维工程师

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

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

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

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

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

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

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

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

Swarm 的问题

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

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

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

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

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

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

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

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

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

Mesos:数据运维工程师

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

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

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

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

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

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

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

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

Mesos 的问题

调度在大数据领域是核心中的核心,在容器平台中是重要的,但不是全部。所以容器还需要编排,需要各种外围组件,让容器跑起来运行长任务,并且相互访问。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 绝对不是像使用虚拟机一样,开发除了写代码,做构建,做测试,还需要知道自己的应用是跑在容器上的,而不是当甩手掌柜。开发人员需要知道,容器是和原来的部署方式不一样的存在,你需要区分有状态和无状态,容器挂了起来,就会按照镜像还原了。开发人员需要写 Dockerfile,需要关心环境的交付,需要了解太多原来不了解的东西。实话实说,一点都不方便。

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

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

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

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

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

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

网易云轻舟微服务是围绕应用和微服务打造的一站式 PaaS 平台,帮助用户快速实现易接入、易运维的微服务解决方案。

相关阅读:为什么 kubernetes 天然适合微服务 (1)

为什么 kubernetes 天然适合微服务 (2)

为什么 kubernetes 天然适合微服务 (3)

文章来源: 网易云社区

赞(0)
未经允许不得转载:优乐评测网 » 优乐综合社区为什么 kubernetes 天然适合微服务 (1)

优乐评测网 找服务器 更专业 更方便 更快捷!

联系我们联系我们