为何 kubernetes 自然适合微服务 (1)

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

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

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

参考

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

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

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

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

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

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

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

有的公司有 ToC 的业务，于是累积了大量的用户数据，公司的运营须要经过这部分数据进行大数据分析和数字化运营，于是在这些企业里面每每还须要关注数据架构。

从事互联网应用的企业，每每首先关注的是应用架构，是否可以知足终端客户的需求，带给客户良好的用户体验。业务量上每每会有短时间内出现爆炸式增加的现象，于是关注高并发应用架构，并但愿这个架构能够快速迭代，从而抢占风口。

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

然而一千我的心中有一千个哈姆雷特，因为原来工做的关系，三类角色分别从自身的角度看到了容器的优点给本身带来的便捷。

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

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

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

因此这三种视角的人，在使用容器和选择容器平台时方法会不同。

2、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）

文章来源： 网易云社区