本文讲的是对于Kubernetes来说，新版本的Docker Swarm意味着什么？【编者的话】本文介绍了Docker 1.12的最新进展，并与Kubernetes进行了简单的比较，阐述了Apprenda选择Kubernetes的理由。
按照软件开发的一般标准来说，容器编排领域正以难以置信的速度发展着，爆发了大量的容器创业公司，竞争也日趋白热化。这对于创新来说是一件好事，但是增加了技术选型的难度。我们正密切关注着Docker和Swarm。
在Apprenda，我们的目标是向一个创新的、稳定的、长期维护的编排技术贡献代码。我们认为，一个健康的社区是这三点的必要条件。对多个不同的容器编排解决方案进行了技术、社区和商业三个方面的评估之后， 我们选择了Kubernetes 。然而，与Kubernetes相比，我们需要了解其他的容器集群管理技术提供了哪些能力，这是很重要的。
Docker会在一周之内发布1.12版本，可能会与Kubernetes直接竞争。新版本会有 内置的编排系统 ，称为SwarmKit。Docker Swarm现在是Docker的一部分了，它引入了一些有趣的新概念。例如，Docker CLI具备了实例化一个Swarm集群的新能力。
实例化一个Swarm集群隐含地创建了一个Swarm Manager和CA（Certificate Authority）。值得注意的是，CA会为Swarm Manager和Swarm集群中的所有节点生成证书，所有节点之间的通信都被TLS保护。这意味着再也不会存在一个不安全的Swarm集群，这是很棒的。现在，对于开发者和工程师创建和使用Swarm来说，安全性是完全透明的。
CLI提供了一些新命令，可以将一个节点加入到已存在的Swarm集群中。值得注意的是，节点有两种角色，要么是manager，要么是worker，但是worker角色可以提升为manager角色，manager角色也可以降级为worker角色。Swarm manager使用 RAFT协议 来选举一个leader，这和Kubernetes与 etcd 的工作方式是相似的。另一方面，workers使用谣言协议（gossip protocol）在他们之间交换状态，因此Docker用户不再需要一个外部实体或者key-value数据库来跟踪集群拓扑时常的变化。
Docker还引入了一个新概念：logical服务，这个概念已经在 Docker Cloud 中使用了一段时间了。该服务包括1对多的容器实例，这种逻辑视图（logical view）使服务管理更加容易。用户可以创建、更新和扩展一个服务，最终表现为部署、更新和销毁容器。
Docker 1.12的一个缺点是服务发现，而Kubernetes中的服务发现是非常优雅的。更重要的是，自Kubernetes项目一开始，容器的服务代理概念（the notion of a "service" proxy）就已经存在了。它可以连接集群中的 服务名 ，Kubernetes将保证你连接到服务背后的pod（一个或多个容器）。Kubernetes是模块化设计的、可扩展的，它的组件可以很容易地交换，这意味着你可以很容易地裁剪Kubernetes，来满足你的需求。
毫无疑问的是，Docker的新版本将直面Kubernetes的竞争，可以用来自动化部署、扩展和操作宿主机集群中的容器集群。很多公司使用Kubernetes，是因为它超强的社区。社区称之为Kube，正在获得企业用户的广泛认可，他们正在探索如何构建云原生的容器化应用。
Kubernetes将它自己描述为，像一个单一系统一样来管理容器集群，从而加速开发和简化部署。Kubernetes是 开源的 ，是由社区开发的，并由 CNCF （Cloud Native Computing Foundation）管理。这与Docker/Swarm是从根本上不同的，后者是由一个独立的创业公司控制，并非由一个开源社区来管理。Kubernetes是很牛的，原因是它引入了Google数十年运行大规模容器的经验、Red Hat多年部署和管理企业中的开源软件的经验、CoreOS的敏捷开发经验和很多其他组织和社区成员的优势。
正式由于一个强大的、多样化的社区，Kubernetes就像瑞士军刀一样灵活。你可以在裸金属架构上、任何一个你能想到的云服务提供商上运行Kubernetes。另一个令人惊讶的特性是，Kubernetes既支持Docker容器，也支持 rkt 容器，并提供了添加其他集群运行时的能力。
最后，Apprenda选择Kubernetes。这是我们尝试过的最鲁棒的解决方案，我们也很自信它能在未来一直支持我们。Apprenda和Red Hat正在尝试提供Kubernetes的 Windows支持 ，从而运行 Windows容器 。需要注意的是，其他集群编排服务也不是一无是处的，就像我之前所说的，该领域正在飞速发展，我们希望能确保与最活跃的、稳定而成熟的项目合作。在使用Kubernetes的过程中，我们感觉非常开心，并在1.0版本之后便使用在生产环境中了。
我们对于Kubernetes的 1.3版本 很激动，新的PetSet特性提供了新的有状态原语（stateful primitives）来运行pods。我们也很期待Kubernetes 1.3中添加的 cluster federation （也就是Ubernetes）。
我们很感激整个Kubernetes社区，感谢他们对于该项目的投入。Kubernetes是一个神奇的技术，满足了我们Apprenda的需求。
按照软件开发的一般标准来说，容器编排领域正以难以置信的速度发展着，爆发了大量的容器创业公司，竞争也日趋白热化。这对于创新来说是一件好事，但是增加了技术选型的难度。我们正密切关注着Docker和Swarm。
在Apprenda，我们的目标是向一个创新的、稳定的、长期维护的编排技术贡献代码。我们认为，一个健康的社区是这三点的必要条件。对多个不同的容器编排解决方案进行了技术、社区和商业三个方面的评估之后， 我们选择了Kubernetes 。然而，与Kubernetes相比，我们需要了解其他的容器集群管理技术提供了哪些能力，这是很重要的。
Docker会在一周之内发布1.12版本，可能会与Kubernetes直接竞争。新版本会有 内置的编排系统 ，称为SwarmKit。Docker Swarm现在是Docker的一部分了，它引入了一些有趣的新概念。例如，Docker CLI具备了实例化一个Swarm集群的新能力。
实例化一个Swarm集群隐含地创建了一个Swarm Manager和CA（Certificate Authority）。值得注意的是，CA会为Swarm Manager和Swarm集群中的所有节点生成证书，所有节点之间的通信都被TLS保护。这意味着再也不会存在一个不安全的Swarm集群，这是很棒的。现在，对于开发者和工程师创建和使用Swarm来说，安全性是完全透明的。
CLI提供了一些新命令，可以将一个节点加入到已存在的Swarm集群中。值得注意的是，节点有两种角色，要么是manager，要么是worker，但是worker角色可以提升为manager角色，manager角色也可以降级为worker角色。Swarm manager使用 RAFT协议 来选举一个leader，这和Kubernetes与 etcd 的工作方式是相似的。另一方面，workers使用谣言协议（gossip protocol）在他们之间交换状态，因此Docker用户不再需要一个外部实体或者key-value数据库来跟踪集群拓扑时常的变化。
Docker还引入了一个新概念：logical服务，这个概念已经在 Docker Cloud 中使用了一段时间了。该服务包括1对多的容器实例，这种逻辑视图（logical view）使服务管理更加容易。用户可以创建、更新和扩展一个服务，最终表现为部署、更新和销毁容器。
Docker 1.12的一个缺点是服务发现，而Kubernetes中的服务发现是非常优雅的。更重要的是，自Kubernetes项目一开始，容器的服务代理概念（the notion of a "service" proxy）就已经存在了。它可以连接集群中的 服务名 ，Kubernetes将保证你连接到服务背后的pod（一个或多个容器）。Kubernetes是模块化设计的、可扩展的，它的组件可以很容易地交换，这意味着你可以很容易地裁剪Kubernetes，来满足你的需求。
毫无疑问的是，Docker的新版本将直面Kubernetes的竞争，可以用来自动化部署、扩展和操作宿主机集群中的容器集群。很多公司使用Kubernetes，是因为它超强的社区。社区称之为Kube，正在获得企业用户的广泛认可，他们正在探索如何构建云原生的容器化应用。
Kubernetes将它自己描述为，像一个单一系统一样来管理容器集群，从而加速开发和简化部署。Kubernetes是 开源的 ，是由社区开发的，并由 CNCF （Cloud Native Computing Foundation）管理。这与Docker/Swarm是从根本上不同的，后者是由一个独立的创业公司控制，并非由一个开源社区来管理。Kubernetes是很牛的，原因是它引入了Google数十年运行大规模容器的经验、Red Hat多年部署和管理企业中的开源软件的经验、CoreOS的敏捷开发经验和很多其他组织和社区成员的优势。
正式由于一个强大的、多样化的社区，Kubernetes就像瑞士军刀一样灵活。你可以在裸金属架构上、任何一个你能想到的云服务提供商上运行Kubernetes。另一个令人惊讶的特性是，Kubernetes既支持Docker容器，也支持 rkt 容器，并提供了添加其他集群运行时的能力。
最后，Apprenda选择Kubernetes。这是我们尝试过的最鲁棒的解决方案，我们也很自信它能在未来一直支持我们。Apprenda和Red Hat正在尝试提供Kubernetes的 Windows支持 ，从而运行 Windows容器 。需要注意的是，其他集群编排服务也不是一无是处的，就像我之前所说的，该领域正在飞速发展，我们希望能确保与最活跃的、稳定而成熟的项目合作。在使用Kubernetes的过程中，我们感觉非常开心，并在1.0版本之后便使用在生产环境中了。
我们对于Kubernetes的 1.3版本 很激动，新的PetSet特性提供了新的有状态原语（stateful primitives）来运行pods。我们也很期待Kubernetes 1.3中添加的 cluster federation （也就是Ubernetes）。
我们很感激整个Kubernetes社区，感谢他们对于该项目的投入。Kubernetes是一个神奇的技术，满足了我们Apprenda的需求。
原文链接：What the New Docker Swarm Announcement Means for Kubernetes（翻译：夏彬）
原文发布时间为：2016-08-01
本文作者：夏彬
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：对于Kubernetes来说，新版本的Docker Swarm意味着什么？
