Docker 1.12 的哪些特性使它更像 kubernetes？

Docker 1.12 版本最近刚刚发布，这篇文章对它的新特性进行了概述和对比描述。本文涵盖了 Docker 1.12 中的六大新特性：内置 swarm 命令、服务发现、自愈功能、安全、负载均衡、滚动升级，相关的使用文档和 demo 视频链接也都包含在里面。

内置 swarm 命令

Docker engine 中增加了 docker swarm 命令，它用于取代之前通过容器创建 swarm 节点的方式。现在，创建一个 swarm 节点，只需要在每个节点上运行一条命令。在第一个节点上运行以下命令：

“<manager-ip>”是该节点的内网 IP ，同一个网段的的其他节点可以通过这个 IP 访问该节点。“<port>” 是该 swarm 与其他 swarm 节点上进行通信的端口。 Docker 文档使用端口 2377 ，但你可以自己指定。

上面的命令运行成功以后，将生成一条新命令，新命令用于将其它节点添加到 swarm 集群。它看起来像这样：

在其它节点上运行上面的命令以后，我们就得到了一个可以正常运行的 swarm 集群。我们对比一下之前和现在部署 swarm 的区别：

之前:

● 要建立一个 swarm ，我们需要在每个节点上启动主 swarm 和代理容器。

现在:

● 不需要 swarm 容器、可以用本地 Docker swarm 命令创建 swarms 。

想了解更多关于如何在 1.12 中建立 swarm ，请查看官方文档（ https://docs.docker.com/engine/swarm/swarm-tutorial/create-swarm/）。

服务发现

服务是一个关键的更新，后面我们会看到，它也促成了很多其它功能的更新。 docker service 命令告知集群中服务的期望状态。这种机制下，当节点或容器挂掉，智能编排服务成为可能。

在定义服务状态时， Docker service 跟 Docker-compose 的概念很相似。 Docker-compose 也有 scale 相关的命令，但缺点在于：这些命令仅第一次确保状态是正确的，但没有持续的监控。有了新的 Docker service 命令， Docker-compose 可能会被打上“仅用于开发”的标签。

在以前的 Docker 版本中，我们必须找到不同的方式来扩展服务，并确保它们拥有期望的的副本数量。一些人用 Kubernetes 或 Amazon EC2 解决这个问题，也可能使用 Docker-compose ，虽然只有在第一次运行时能够保证服务的状态。

之前

● 我们使用其他工具如 Kubernetes 或配置文件来定义服务，用于 Amazon EC2 照顾容器编排。

现在

● 使用 Docker service 告知 swarm 服务的期望状态，这意味着 Docker 原生支持服务编排。

有关如何部署服务的详细信息，参见这里

（ https://docs.docker.com/engine/swarm/swarm-tutorial/deploy-service/）。

自愈能力

目前， swarm 集群完全具备自愈能力。任何服务宕掉后， Docker engine 本身就可以对它进行重新调度，不需要任何其它编排工具。

以前我们需要一个外部编排层（如 Kubernetes ），现在编排这一层已经内置到 Docker engine 中。

添加和删除节点后， swarm 集群都能够正常工作，从这个层面上来说 swarm 是可伸缩的。尽管 swarm 没有挂掉，且可伸缩，但是它不能编排容器。

如果一个 swarm 节点挂掉，容器集群不能感知到到它需要在另一个节点上启动一个新容器，从而取代挂掉的主机上的容器。在 Docker 1.12 中，这种情况不会再出现。

在 Docker 1.12 中，当服务的容器个数不满足要求时， swarm 会自动在其它节点上启动新容器。

虽然这是一个巨大的飞跃，但它仍然有些地方需要改进。如果你添加新节点到一个 swarm 集群，并想把服务的部分容器调度到新添加的节点上， swarm 还不能满足你的需求，但这一点会很快改善。

之前

● 虽然 swarm 集群本身具有自愈能力，但是 swarm 上的容器不支持此特性。我们不得不手动或借助工具（如 Kubernetes ）来确保服务的实例个数达到期望值。

现在

● swarm 现在意识到服务应该运行在集群上，当容器或节点宕掉时会重新调度。

关于 swarm 如何面对节点故障并重新部署已经被杀掉的服务，查看官方完整的 demo ：

（ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=8m13s ）。

安全

在 1.12 中， Docker 负责所有节点之间的加密。我们很早支持 swarm 节点间的加密通信，但是迄今为止，配置一直是一个痛点。因为我们需要一个根证书认证服务器。

现在， Docker 在每个节点上都运行一个 CA 服务器，这使得 CA 服务器可以在默认情况下的节点间启用 TLS 加密。

设置手动加密的另一个痛点是认证循环，但是 Docker engine 1.12 已经为我们做了这些事情。

因此，现在加密 swarm 节点间通信不仅更容易，而且是默认启用！

之前

● swarm 节点之间的通信可以使用 TLS 加密，但需要额外设置。如果你真的想这么做，需要设置 CA 或使用第三方的根证书。

● 当证书过期时你需要管理证书

现在

● 所有节点间的通信在默认情况下进行加密， swarm 绑定 CA 并为你管理证书，包括证书循环。

了解更多关于 Docker 1.12 如何负责节点间加密的更多信息，参考这篇官方博客文章（ https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/）。

负载均衡（路由网）

Dockers 路由网使网络变得更容易。关键的概念是，如果你在服务上发布一个端口，它是跨整个集群全局发布的，所以在任何节点上的端口都可以到达该服务。

同时， Docker 内部负载均衡要求一个可用的容器。这意味着你服务中任意节点上的请求都将跨重复的容器进行透明负载均衡，即使容器在不同的节点上传播，或者节点的请求来自容器所在的不同节点。这真的很酷，可以让我们减少很多工作。

如果你需要 SSL 或代理请求到多个服务（不是跨服务的负载均衡），那么无论如何你都需要设置代理。最大的不同是，代理不需要跨单个容器上负载均衡，只需要跨服务进行负载均衡，这样代理就更简单了。

之前

● 要对一个服务的几个副本容器设置负载均衡，那么需要设一直一个 proxy ，通常使用 nginx 、 haproxy 等工具配合 consul 动态配置容器的 IP 。

现在

● 开箱即用的负载均衡， swarm 上公开暴露的端口在所有节点都是可以访问的。

● 不需要知道容器的 IP 地址，而是通过服务名称。 Docker 处理不同容器副本的内部路由和负载均衡。

关于如何使用路由网，看看这个演示视频

（ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=3m18s ）。

滚动部署

这是一个非常酷的功能。由于 Docker engine 已经知道集群服务的期望状态，对 Docker engine 发送指令，让它逐个更新副本（或两个两个的，使用 --update-parallelism 标签来配置）。这意味着我们可以安全透明的更新容器副本。

关于“透明”，你当然要确保你的容器是向后兼容的，否则最好销毁旧的容器，再去更新所有的容器。重点是虽然有了滚动更新以后，我们就不需要把更新规则写成脚本去实现透明部署。

之前

● 必须手动管理部署，或者蓝绿部署，或者手写脚本实现滚动升级。

现在

● 使用更新服务的命令实现滚动升级。

Docker 的团队做了一个滚动更新的演示视频，看看这里

（ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=6m38s ）。

Docker 1.12 使管理 Docker swarm 整体更简单容易。不需要外部编排（如： consul ），这意味着较少的移动部件。有了这些变化， Docker 正慢慢成为目前占据主导地位的编排工具（如 Kubernetes ）的真正替代者。我们拭目以待。

本文由时速云翻译，如若转载，需注明转载自“时速云”

原文链接： http://blog.nimbleci.com/2016/08/03/whats-new-in-docker-1.12/