Docker 管理工具的选择：Kubernetes 还是 Swarm？

【编者的话】选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。

Docker 容器技术已经成为推动云技术发展最重要的技术之一。如果你还没有使用容器技术，那么你很可能很快就会使用到它，不管以什么样的方式。

使用这种技术有两个步骤。首先，你需要理解容器的概念。然后你需要有一个编排工具来处理容器的调度和管理。最终选择谁取决于技术偏好和需求。

Docker是一种高级技术，能给用户带来很多计算方面的优势。这篇入门介绍是该复杂的计算机进程的一个概要。将使用简单直接的方式呈现它的基础知识。

Docker是一个容器的软件平台。容器将一个计算任务 - 或者一系列任务 - 所有需要的东西打包然后在隔离的环境中运行它们。简单来说，容器能为一个软件包提供运行的平台，而不需要一个完整的操作系统的支持。

这个简单的描述让容器听起来就像一个被吹嘘的虚拟机。但是这并不正确。一个VM可以部署很多的服务，并在一个计算机上运行不同的计算进程。然后这个宽泛的解释基本上一样适用于容器，它们的不同点在于部署方式。

例如，这两种方式的一个本质区别是用来运行它们的裸机（bare metal）。VM需要一个宿主计算机，并且必须要能共享它的资源。VM 运行在 hypervisor 上，其充当管理工具的功能。结果，不是所有的计算机都能支持虚拟复制。

这个支持取决与计算机的处理器。这个限制是巨大的。要在一个计算机上运行很多的VM会话或者服务器受到宿主机器资源富裕量的限制。

虚拟机需要依赖于一个安装好的操作系统才能运行。而容器，只需要操作系统的某些部分就能运行。这意味着容器的运行效率更高、资源占用更少，使得它们相较于VM更实用，发挥更好的计算作用。

另外一个重要的差别是VM可以在隔离的环境下运行应用，而容器没有独立运作的能力并因此遭致问题。因为容器没有操作系统或者 hypervisor，它们需要有自己的管理系统。

目前有两个流行的开源技术在这个容器控制领域进行竞争。Docker开发了Swarm，现在将它整合进了 Docker Toolbox。另外一个更加成熟的容器管理器是 Google 的Kubernetes。它们都解决了缺乏独立运行能力的问题，通过提供一个能跨多主机、多数据中心、多云环境运行的系统。

选择权在你手里。不管你选了哪一个，Docker都能运行的很好。决定那个工具最好，首先是要理解它们的不同点。

Kubernetes

Kubernetes是一个开源的可以用来自动部署、伸缩和管理容器化应用的系统。Kubernetes集群包含一些基本组成部分。这里是简要的概括一下：

Kubernetes成组地部署和调度容器，这个组叫Pod，常见的Pod包含一个到五个容器，它们协作来提供一个 Service。
Kubernetes默认使用扁平的网络模式。通过让在一个相同 Pod 中的容器共享一个 IP 并使用 localhost 上的端口，允许所有的 Pod 彼此通讯。
Kubernetes 使用 Label 来搜索和更新多个对象，就好像对一个集合进行操作一样。
Kubernetes 会搭设一个 DSN 服务器来供集群监控新的服务，然后可以通过名字来访问它们。
Kubernetes 使用 Replication Controller 来实例化的 Pod。作为一个提升容错性的机制，这些控制器对一个服务的中运行的容器进行管理合监控。

Swarm

Docker的开发者现在将Docker Machine、Compose 和 Swarm 整合进了 Docker Toolbox 中。你可以对这三驾马车进行配置来让它们负责容器的配置、管理或者集群化容器。

Docker Swarm，现在作为一个 beta 版本，是一个 Docker 的集群化工具。它通过使用一个或者多个 Docker 主机来组成一个 Swarm 集群。 Swarm 的设计是将容器打包到主机上，所以它能为更大的容器预留其他的主机资源。较之于随机地将容器调度到集群中的一个主机上，这种集群的组成方式能取得更加经济的伸缩性能。

下面是 Swarm 和 Kubernetes 关键的不同点：

Swarm 有能将一组 Docker 引擎转变为一个虚拟的 Docker 引擎的原生能力。
一个 swarm 只包含两个组件：agent 和 manager。
一个集群有一个主机来运行一个 Swarm agent，另外一个主机来运行 Swarm manager。
这对于运作来说是必要的，因为 manager 负责容器在主机上的编排和调度。
Swarm 使用一个发现机制来处理主机的发现和向集群的添加。
Swarm 提供了标准的 Docker API。这使得它提供了开箱即用的能力，能让所有既有的 Docker 管理工具 - 包括第三方的产品- 能自动地、透明地在多个主机上进行伸缩。

细微的不同点

两种方式 - Kubernetes 和 Swarm 都能处理同一种类型的工作负载，以云原生应用的方式。然而，一个很大的不同点是如何处理伸缩。

在Kubernetes中，每一个应用层被定义成一个 Pod。一次部署或者复制控制器可以手工地或自动地处理伸缩。在Swarm中，对于单个容器的伸缩定义在 Compose 文件中。

其他的不同点在于管理器系统如何处理高可用、负载均衡、应用滚动更新和回滚、日志和监控、存储、网络、服务发现以及性能合伸缩性上。

结论

Kubernetes 和 Swarm 都能大规模构建虚拟的容器。它们提供了用来取得同样目标的两个方式。它们有不同的运作方法，提供了可能更加适合你特定需求的功能。

不要仅仅因为 Docker Swarm 是Docker Toolkit 自带的就是用它作为解决方案。首先，让你的 IT 团队的成员上手熟悉两种工具。然后让 IT 团队根据自己公司的情况来建言，哪一种方式配置和部署更加容易。

用最简单的比喻来说，选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

原文链接：Choose your Docker Management Tool: Kubernetes or Swarm（翻译：钟最龙）