Kubernetes 和 Docker Swarm 都是受欢迎的著名容器编排平台。虽然您不需要用容器协调器来运行容器，但因为它们对于保持容器健康意义重大，所以需要多了解。

最近你为容器编排做了什么？

或许你没使用 Kubernetes 或者 Swarm 来完内部项目，但你一定也曾受益过。

例如，提供iHCM（一个人力资源管理平台）和工资单服务的 ADP（美国自动数据处理公司），正使用Docker的EE产品(基于 Swarm )来运行他们的一些关键系统。ADP的首席架构师 Jim Ford 说，他们的生产数据中心里有600个节点正在运行EE，约占总结点数的40%。

即便你是一个普通的GitHub用户——在后台，Kubernetes代码也正在为你运行，想了解详情请阅读《GitHub上的Kubernetes》这篇文章。

以下是容器编排平台的一些功能:

1. 集群 ( 计算能力跨多个机器 )
2. 编排 ( 平台决定代码应该在哪里运行 )
3. 高可用性 ( 不止一次运行您的代码副本 )
4. 容错 ( 如果您的一个代码副本变得不健康或崩溃，它可以自动重新启动 )
5. 机密管理 ( 在主机之间安全地共享秘密变得更容易了 )

因此，如果您在生产中正在使用按照容器方式运行的应用程序，那么您需要了解容器编排是否会起到帮助作用。

让我们先来看一下 Kubernetes 和 Swarm 这两个平台之间的一些不同之处。

分工

Docker Swarm被打包成两种产品—— Docker CE ( 免费和开源 ) 和 Docker EE ( 面向企业和商业 )。Docker Swarm 自 Docker 1.12 版本以来，就内置在了Docker的安装过程中，并成为主要二进制文件的一部分。

在 Docker 1.12 版本发布之前，有一个早期的项目也叫 Swarm ，它是为使用 Docker 的远程 API 而开发的。

Docker 的 Linux 发行版由许多项目和组件构成，但它只提供了一些二进制文件如：客户端、守护进程和容器。在内部，它使用 RunC （ Docker背后的标准化容器执行引擎 ）来运转容器，而 SwarmKit 项目提供了编排。二进制文件太小，甚至可以在树莓派 512mb 的 RAM 上运行。

Kubernetes 则采取了一种不同的方法来建立系统。Kubernetes有一种 UNIX 的味道，它分成一系列单独的项目，这些项目组来做分工。一个示例是 kubelet ( 运行容器 )、kubectl 来负责客户端 CLI （命令行界面）和 API Server ，它在主机上运行，以提供对API的访问。

Kubernetes 需要至少 1GB 的内存，所以不会在低端的物联网硬件上运行，而且二进制文件很大。Justin Cormack（维护 Docker 引擎的负责人）说，Docker 大约是 150 mb，而 Kubernetes 则是1.5 GB 左右。

Docker Swarm 则较小，在默认情况下，它包含在 DockerCE 中，移动部件也更少。Kubernetes 则需要更多的资源，但是可以由任何东西组成，哪怕仅是某个解决方案中的一部分。

原始

对于 Docker 来说，基本的元素始终是一个容器，但对于 Docker Swarm ，则拥有一个声明式的配置服务。该服务表示 Swarm 中需要创建的状态——然后 Swarm 将尝试实现这一目标。

当一个服务创建一个容器时，它被称为任务。服务组通常被放置在一个自定义的网络上，通过使用“ Docker栈 ”来简化——即 Docker 组合的替代品。

在 Kubernetes 中，还有声明式配置，可以在命令行上指定，也可以通过 YAML 文件指定。YAML格式更复杂，但也更通用——幸运的是说明文档中会有很多例子。

计算的基本单元是一个或多个相关的容器，它们在同一个主机上运行，在同一个网络上可以相互访问——它们甚至可以共享存储卷。当某些初始化代码需要在容器启动之前运行时，Pod 概念此时就显得非常强大。

Pods 通过部署获得高可用性——这与 Docker服务类似，而且已经超越了一个名为“ReplicationController（复制控制器）”的老式 Kubernetes 类型。

无论是使用 Kubernetes 的部署，还是 Docker Swarm 的服务——当容器崩溃时，服务都会变得不健康或导致正在运行的节点离线，但二者都有正确的办法来恢复。

CLI

Docker Swarm 的 CLI 与 Docker 共享。有两个新的命名空间对Swarm很重要:

初始化/加入一个 Swarm ：

docker node COMMAND

Docker 还提供了针对不同云的产品，比如 Docker 为 AWS/Docker 提供 Azure 服务。

管理/列表节点：

docker node COMMAND

创建/管理/列表 Swarm 服务 ( 容器部署 )：

docker service COMMAND

命令可以直接在主节点上运行，或者远程访问设置了安全传输层协议的主节点。CLI通常与整个 Docker/EE 包一起发布。

Kubernetes CLI 被称为 kubectl，它可以在基于debian的系统上或通过 GitHub 获得。与 swarm 不同的是，kubectl 只用于管理部署和集群配置——它不用于创建集群。

要创建集群，请使用第三方工具：

1. kops - 创建一个在AWS上可管理的生产集群
2. GKE-创建一个完全由Google Cloud管理的生产集群
3. kubeadm——创建一个具有单个主机的开发集群

Kubernetes是由许多独立的部分组成的，你可以手动或“物理化”地使用 Kelsey Hightower 这个指令。

kubectl get pods --all

获取正在运行的容器，Nginx在30秒内就能做到。

Nginx是一个受欢迎的网络服务和反向代理，推荐将Nginx 作为 Docker Swarm 的一项服务。

$ docker service create --name nginx --
publish 80:80 nginx:latest

端口80通过服务网格自动地在集群中的每个节点上公开。

检验,然后删除：

$ docker service ls
$ docker service ps nginx
$ docker service inspect nginx
$ docker service rm nginx

Kubernetes：

$ kubectl run nginx --image nginx:latest --port=80
deployment "nginx" created

这将在网络的一个节点上创建一个可部署和可调度的 Pod ，它还没有暴露在集群之外。

现在，您必须在一个负载平衡器 ( 只能在云主机上可用 ) 、一个用于管理程序的控制器(需要Nginx或Traefik单独安装)，或一个 NodePort 之间进行选择。

下面是如何使用NodePort:

$ kubectl expose deployment/nginx
--type="NodePort" --port 80

现在可以通过在节点上找到对应的端口来访问部署。

$ kubectl get services
NAME     CLUSTER-IP       EXTERNAL-IP   PORT(S)
nginx    10.110.240.60
<nodes>  80:31359/TCP     18s

您可以在端口80上使用10.110.240.60的集群-IP，或者使用NodePort和节点的IP，即192.168.0.45:31359。

检验/删除:

$ kubectl describe deployment/nginx
$ kubectl get deployment
$ kubectl delete deployment/nginx
$ kubectl delete service/nginx

Docker Swarm 的网络模型在默认情况下使用“覆盖网络”，这是一种软件定义的网络 ( SDN ) 。最近的变化意味着数据层和控制层可以在不同的接口上运行。Docker Swarm 的新选项中，包括主机联网和一个名为“macvlan”的虚拟机(VM)特定网络选项。供应商可以提供额外的网络驱动。

而 Kubernetes 能够实现网络的“不插电”——你只需要针对将哪些第三方软件加载到集群中提供网络连接，做出一个有指导意义的决定，大多数情况下将使用一个软件定义的网络 ( SDN ) ，如:Weave、CoreOS或Nuage。

如果你正开始学习Kubernetes，或者把它用于开发，那就选择Weave 或 Flannel 。而对于生产环境，你就需要做好家庭作业，看是否需要为“支持”付费。

API /集成

Docker Swarm 的 API 是通过 moby项目提供的，可以用于自动化容器编排。你还可拥有 Docker CLI 所能做的一切——也就是构建镜像。

Kubernetes 项目在 GitHub 上提供了一个 Golang客户端。它的执行时间超过了 Swarm ，这意味着你必须准备好一组复杂的名称空间和 API 对象，以及更大的代码目录。在英特尔 i5 处理器上，Golang的示例运行可以花1.5-2分钟。

我已经能够在 OpenFaaS 项目和一些边缘项目中使用这两个api，它们都工作的很好。

规模

我不敢确定 docker/kubernetes 的用户数量会扩展到一个很大的量级。但无疑，可扩展是编排和集群系统的一个卖点。

在 Docker Swarm 或 EE 的最大支持范围内，我无法找到任何公开的声明。Chanwit Kaewkasi （《Swarm容器编排与Docker原生集群》一书大的作者）的两个社区项目在研究这个—— Swarm2k 和Swarm3k 。

Kubernetes的最大支持范围在v1.8中列出了，即5000个节点集群的支持。注意，如果有更大的系统，可以单独运行多个集群。

结语

我们中的许多人都听到过 ADP 首席架构师 Jim Ford 的 “ 创新或死亡：容器才是救世主 ” 之类的言论。

当时 ADP 的首席技术官Keith Fulton在2016年的Dockercon会议上说，“现在每个公司都是一家科技公司，这是一场比赛，没有终点线。”

在云计算领域，容器技术对于在这个永无止境的比赛中保持竞争力至关重要。

你可能想知道从哪里开始，如何选择编排工具?

我的建议是：把两者都学会。

Docker Swarm 和 Kubernetes 在很多方面都有不同的地方，但它们有足够的相似之处，你可以在你的学习中进行转换，并就什么对你的团队或项目来说是正确的做出决定。

编译：晓宽
作者：Alex Ellis
来源：
https://blog.alexellis.io/you-need-to-know-kubernetes-and-swarm/