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

　　经过一段时间的思索，以及采访了从早期就开始实践 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 虽然复杂，但是设计的都是有道理的，符合微服务的思想。