Docker Engine v1.12于2016年7月发布，它是v1.9以来最重要的版本。从那时候起，我们可以使用Docker的网络功能，并最终使容器可以在集群中使用。在v1.12中，Docker正在以一种全新的集群编排方法重塑自己。Swarm作为一个独立的容器依赖于外部数据注册表，告别它之后，我们迎来了Docker Swarm或Swarm模式。你需要管理集群的所有工具现在都集成到Docker Engine里了。Swarm有了，服务发现有了，改进之后的网络也有了。Docker Engine现在整合了我们需要的所有“必要的”工具。
旧版Swarm（在Docker v1.12之前）使用了fire-and-forget原理。我们发送一个命令给Swarm master，它会执行那个命令。例如，如果给它发送像docker-compose scale go-demo=5这样的命令，那么旧的Swarm会评估集群的当前状态，比如发现当前只有一个实例正在运行，可能会决定再启动四个实例。一旦做出这样的决定，旧的Swarm会向Docker Engine发送命令。结果，就有五个容器在集群内运行。为了达到这样的效果，我们需要在组成集群的所有节点上设置Swarm代理（作为单独的容器），并将它们连接到一个被支持的数据注册中心（Consul、etcd、Zookeeper）。
问题在于旧版Swarm只是在执行我们发送的命令，它并没有维护我们想要的状态。实际上我们告诉了它想要做什么（如扩大规模），而不是我们想要的状态（确保有五个实例正在运行）。后来，旧版Swarm有了重新安排失败节点容器的功能。但是，该功能有一些问题妨碍了它成为可靠的解决方案（例如，没有把容器从覆盖网络中移除）。
现在有了一个全新版Swarm，它是Docker Engine的一部分（不需要将它作为单独的容器运行），它包含服务发现（无须设置Consul或任何你选择的数据注册中心），它一开始就被设计为接受并维护期望的状态，等等。这是我们处理集群编排方式的重大改变。(www.xing528.com)
相比于Kubernetes，以前我更喜欢旧版Swarm。然而，这种倾向只是轻微的。使用任何解决方案都有利弊。Kubernetes具有Swarm缺少的一些特性（例如，期望状态的概念），旧版Swarm以其简单和资源利用率低而著称。
有了新版Swarm（v1.12），我就不再犹豫了，新版Swarm是比Kubernetes更好的选择。它是Docker Engine的一部分，因此，所有设置只是告诉引擎加入集群的命令。新的网络功能就像魔法一样。可以用来定义服务的包，可以从Docker Compose文件创建，所以不需要维护两套配置（Docker Compose用于开发，另一套用于编排）。最重要的是，新版Docker Swarm依然简单易用。
下面将从版本1.12中引入的一些新功能开始介绍。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
