编排管理成容器云关键 Kubernetes（K8s）和Swarm对比分析

淡淡的烟草味﹌ 2022-07-14 01:00 209阅读 0赞

> 不论是公有云还是私有云环境，Docker 在新一代技术架构中的重要地位已经毋庸多言，甚至已经有企业在探索完全 [Docker][] 化。在此背景下，如何选择容器技术栈就成为了企业实践的关键。回答这个问题，首先需要厘清技术体系更新的逻辑，再看可选技术是否符合需求。本文认为，容器的管理和编排将是容器云的关键，而 [Kubernetes][] 是最为成熟的编排技术。

## 容器管理和编排将成云计算主战场 ##

从云化的诱因说起。中国云计算实践八年多，市场认知逐渐提升，锐意创新企业对云的期待已经不是资源弹性、成本优势那么简单，业务的灵活性和稳定性才是直接目标，当然这背后的应用弹性是研发部门要考虑的，所以 [DevOps][]的理念正在刺激技术团队的神经，敏捷、灵活、高效的容器技术和微服务架构越来越被关注。

Docker 的理念为“Build, Ship and Run Any App, Anywhere”，通过容器和镜像的特性让 DevOps 变得容易，但 Docker 的前景，更在于支持分布式、服务化设计，实现一系列可独立开发、独立部署和独立扩展的服务组合，以保证业务的灵活性和稳定性。当前AWS、微软、阿里云、IBM、Redhat、VMWare、华为、Intel 等各大公有云和私有云提供商都不约而同地大力投资 Docker，实际上就是认可了这样的趋势。当然，各家技术的选择和产品化的程度是另一回事了。

符合企业需要的容器云技术架构，需要符合DevOps、微服务的方向，能支持分布式应用，故而合适的容器的管理和编排（Orchestration）工具尤为重要。初级的编排，是资源的编排，即针对物理机或者虚拟机；但更高层次的是服务的编排，需要对架构层次在整体上有一个完整的定义。新浪微博平台运维架构师王关胜就曾经分享说，容器编排的核心内容包括服务定义、资源管理、容器调度、服务检测和服务发现等五个方面。

所以说，容器的管理和编排正在成为容器云的主战场。Docker 公司推 [Swarm][] 技术，收购专注于编排的 Conductant 公司，正是为此。

## Docker Swarm VS Kubernetes ##

当前主流的容器集群管理技术，包括了 Docker 官方的 Docker Swarm、Twitter 背书的 Mesos 和 Google 背书的 Kubernetes。由于Apache Mesos 只是一个分布式内核，目前的发展方向是数据中心操作系统（DCOS），它同时支持 Marathon、Kubernetes 和 Swarm 等多种框架，连 Mesosphere 也是 Kubernetes 生态的一员，从编排的角度，讨论 Mesos 意义不大，故而只对比 Docker Swarm 和 Kubernetes。

### 1. Docker Swarm ###

Docker Swarm 是 Docker 官方推出的容器管理工具，支持容器的跨宿主节点的集群管理，这让传统的云计算资源管理方式有了新的发展。Docker Swarm 的推出，也是 Docker 从善如流的结果。因为 Docker 曾在很长一段时间内只能运行在单个宿主机上，这让外界和社区感到不满意。于是 Docker 在2014年12月推出了第一个版本的 Swarm，同时发布的 Docker 工具还有 Machine 和 Compose – 后者是 Docker 收购来辅助完善容器编排的产品。

年轻的“三剑客”并不能立即让 Docker 集群对分布式应用的支持达到炉火纯青的境界，外部出自 Google 的 Kubernetes 项目横空出世，提供另一种方案，而内部的 Swarm 目前也正在不断完善之中。Swarm 的最新进化，是在今年 6 月 DockerCon 大会上发布的 Docker 1.12 内置了 Docker 公司声称的“最佳的容器编排工具”——Swarm 模式（Swarm mode），引入了服务的概念，不再以容器作为主要管理对象单元，不再需要额外的KV存储支持服务模型，让扩容缩容、服务发现、滚动更新、负载均衡和路由等功能都更容易实现。

![20161115194645][]

作为 Docker 的编排模式，Swarm mode 是通过独立开发的 SwarmKit 项目来实现的。SwarmKit 的主要功能包括节点发现、基于raft算法的一致性和任务调度等。SwarmKit 通过 Containerd 类似的方式接入Docker Engine，最终通过新的 Docker API 对外提供容器集群服务。根据 Docker 公司的态度，Swarm mode 将会取代之前的 Docker Swarm。新的 Swarm 吸收了 Kubernetes 的一些优点，但作为内置的可选工具让开发者更易于使用——不用另外部署第三方的 Kubernetes 了。

![20161115194704][]

### 2. Kubernetes ###

Kubernetes 是一个以 Google Borg 为原型的开源项目。Borg 是 Google 内部使用的集群管理工具，迄今已在 Google 生产环境中运行15年，说久经考验并不过分。Google 新书《Site Reliability Engineering – How Google Runs Production Systems》里面强调，其全球百万台服务器正是通过 Borg 来实现高效管理的，可谓能力卓绝。本来 Borg 是 Google 的秘密武器，但 Google 为了赢得容器云之战，基于 Borg 的经验，结合了来自社区的顶级创意和实践，构建了支持 Docker 容器的 Kubernetes，并将后者开源。

Kubernetes 功能完善，资源调度、服务发现、运行监控、扩容缩容、负载均衡、灰度升级、失败冗余、容灾恢复、DevOps等样样精通，可实现大规模、分布式、高可用的 Docker 集群，Kubernetes面向 PaaS，它直接为解决业务的分布式架构、服务化设计，完整定义了构建业务系统的标准化架构层，即Cluster、Node、Pod、Label等一系列的抽象都是定义好的，为服务编排提供了一个简单、轻量级的方式。

![20161115194712][]

Kubernetes 目前也已经被大量的云计算技术提供商和用户采用，如 eBay、Yahoo、微软、IBM、英特尔、华为、VMware、HPE、Mirantis、网易、普元、亚信等，当然还包括国内的多家容器云初创公司。

Kubernetes 社区的支持者，则包括（但不限于） Google、Redhat、CoreOS、华为、浙大SEL（浙江大学软件工程实验室）、网易等。Google 卯足了劲儿推广 Kubernetes，在去年不仅加入 OpenStack 基金会，还联合其他20家公司成立开源组织 Cloud Native Computing Foundation（CNCF），就是要保证 Kubernetes 未来在任何基础设施（公有云、私有云、裸机）上都能良好运行，并将推动开源以及合作伙伴社区共同开发容器工具集。

![20161115194720][]

### 3. 主要特点对比 ###

结合上文，将 Swarm 和 Kubernetes 最新的主要特点对比如下，可见 Kubernetes 增加了很多应用级别的功能，适用于快速应用的部署和维护。

![20161115194758][]

### 结论 ###

基于 Borg 成熟的经验打造的 [Kubernetes][]，为容器编排管理提供了完整的开源方案，并且社区活跃，生态完善，积累了大量分布式、服务化系统架构的最佳实践。SwarmKit 当然还会迭代会更加优秀的版本，但一来模式有根本的不同，二来完善还需要时间。同时，Docker 公司对未来容器编排管理的技术路线也有挑战，把编排的精华加入 Docker，自然有利于开发者获得集群的能力，却也颠覆了系统级程序专注、松耦合的理念，新架构在生产环境中的稳定可靠，可能还需要更多的说服力。此外，Docker 推出不完全开源的 Docker Datacenter 商业套件，也有可能让社区和生态玩家对 Docker Engine 的商业倾向有所担忧。

所以，从设计模式、工具链、最佳实践和商业模式来看，Kubernetes 都是目前更加让人放心的容器编排管理技术。

## 网易蜂巢 ##

完全基于 Kubernetes + Docker 构建云平台的三大理由

作为 Kubernetes 的拥护者之一，网易没有做折中的方案，而是旗帜鲜明地完全基于 Kubernetes 和 Docker 打造网易蜂巢容器云平台。这是因为 Kubernetes 的设计理念和网易对云计算的认知完全吻合，网易蜂巢希望借助 Kubernetes 成熟的架构设计、强大的社区支持和丰富的业界实践，突破传统 IaaS 资源模式的局限，真正地为企业业务研发效率提速。

### 1.知识体系的Mr Right ###

尽管中国企业越来越认同开源以及基于开源的标准化，但具体到如何趟过开源的坑，将其用于生产环境，这就是多数企业的难题了。网易蜂巢选择 Kubernetes 的另一个重要原因，正是为了基于 Kubernetes 积累的最佳实践建立一个知识体系来破解这种局面。

具体而言，在当前中国的互联网+以及云计算实践中，引入新的技术架构是必然的（可参考 Garter 提出的“双模 IT”），但企业技术水平参差不齐，其实践需要具体的指导。例如，说到微服务设计，HeroKu 提出的十二要素原则是公开的，但要如何正确理解和应用这些原则，还需要哪些与时俱进的新原则，都是很微妙的事情，需要既有的最佳实践作为参照物。所以，网易云在发布产品体系的同时，也宣布推出了知识体系和服务体系，通过专业课程、培训服务和专家服务，用体系化的互联网思想、知识和方法论，帮助客户顺利地构建互联网业务系统。

在这个层面上，蜂巢提供基于 Kubernetes 生态的解决方案还有进一步的意义。因为Kubernetes 积累了社区对分布式、服务化系统架构的最佳实践，而网易蜂巢能够将构建互联网产品的最佳实践通过课程等知识体系传递给用户，帮助用户成功，所以 Kubernetes 这样成熟开放的生态，是蜂巢的必然选择，同时也是想用好容器技术实现产品技术升级的用户的最佳选择。

### 2. 推崇开源的必然 ###

云计算和DevOps实践要与业务结合，需要丰富的工具链，关键框架的最佳选择是开源技术。透明的开源技术，一来有利于技术标准化，实现不同服务商工具的协作，也不会有厂商锁定；二来有利于社区群策群力完善技术体系，共同解决业务架构的问题。而以一家公司（或者一家公司加上有限的合作伙伴）的封闭生态，就很难打造出与整个开源社区共同努力相媲美的产品。这一点，可以参照《大教堂与集市》一书的实际影响。事实上，现在不管 BAT、中移动、银联还是京东、携程、新浪，各行业大大小小的企业，都再大量使用了开源技术。致力于场景化云服务的网易云，自然也是开源的拥护者。

SwarmKit 被 Docker 公司在 DockerCon 大会前夕开源，用于提供容器集群以及编排能力，足见了 Docker 官方改造 Swarm 的诚意，这应该赢得所有人的尊重。同时，Docker 公司提供的更为完整的容器云部署商业方案 – 其在 2016 年初发布的 Docker Datacenter（简称DDC），也包含了一系列的开源项目和商用软件，其中 Universal Control Plane（简称UCP）就嵌入了 Swarm 实现对 Docker 环境的管理与编排能力。可见，开源是有远见的选择。

![20161115195601][]

### 3.标准化的优选 ###

开源其实不是最终目的，而是标准化的需要。事实上，Docker 也在去年和Linux基金会推出了开放容器计划（Open Container Initiative，曾用名Open Container Project），成员包括微软、RedHat、Amazon、CoreOS、Twitter、Intel、Sysdig 和 Oracle 等，希望建立一个通用的容器技术标准。因为日趋复杂的业务需要多种工具，技术不能标准化会意味着“巴别之难”的隐患。作为核心的编排技术更是如此 – 使用轻量级的 Docker 容器，本来就是要服务化，更灵活地支持业务，如果容器编排管理层使用非标准化的技术，岂非与初衷大相径庭？

Kubernetes 基于构建应用栈提供的完整、合理的抽象，已经通过开源生态推行成为容器编排管理的标准。作为开源商业模式的老手， Redhat 在重写其 PaaS 平台 OpenShift 时，就选择了 Kubernetes 作为容器集群管理技术。作为公有云的网易蜂巢，要为客户提供解决业务问题的解决方案，采用 Kubernetes 技术标准化，正是顺势而为。

而根据国外试用 SwarmKit 的用户总结，SwarmKit 是对现有调度及编排生态系统的一种有益补充，但其功能的丰富程度尚不及其它调度方案（比如还没有配置管理、服务选择等），而且它似乎并不打算发展为适合任意用户、任意任务的普适型解决方案。

原文：编排[管理成容器云关键 Kubernetes（K8s）和Swarm对比分析][Kubernetes_K8s_Swarm]

[Docker]: http://www.kubernetes.org.cn/tags/docker
[Kubernetes]: http://www.kubernetes.org.cn/
[DevOps]: http://www.kubernetes.org.cn/tags/devops
[Swarm]: http://www.kubernetes.org.cn/tags/swarm
[20161115194645]: http://img.kubernetes.org.cn/2016/11/20161115194645.jpg
[20161115194704]: http://img.kubernetes.org.cn/2016/11/20161115194704.jpg
[20161115194712]: http://img.kubernetes.org.cn/2016/11/20161115194712.jpg
[20161115194720]: http://img.kubernetes.org.cn/2016/11/20161115194720.jpg
[20161115194758]: http://img.kubernetes.org.cn/2016/11/20161115194758.jpg
[20161115195601]: http://img.kubernetes.org.cn/2016/11/20161115195601.jpg
[Kubernetes_K8s_Swarm]: http://www.kubernetes.org.cn/757.html