7 个选择 Kubernetes 作为你的 Docker 编排工具的理由

摘要

对于 Docker 编制框架来说， Kubernetes 是最强的竞争者之一，这在版本 1.2 之后更是如此。如果你正在寻找一种部署 Docker 容器到你的任一环境中的方法， Kubernetes 给你至少 7 个选择它的理由。

Ⅰ Deployments

在 K8S1.1 中默认设置中， Deployments 是 alpha 版。在 1.2 中，当你开启一个新的集群的时候， Deployments 功能开启 beta 版，被认为是稳定的，并且可以运行。

为什么在 K8S1.1 中部署程序显得有些乏味，点击这里阅读更多信息： https://engineering.nanit.com/real-world-deployments-on-kubernetes-68fa81396dad#.rw2succxq

在这里我就不赘述具体细节了，这里的要点是:

1.你得自己计算每个部署的唯一值，然后把它放到 Replication-Controller 定义文件。

2.首次创建以及更新已经存在的一个 Replication-Controller ，你得有不同的进程。

3.在你能够通过滚动更新配置一个新的版本后，你得在系统里找一个存在的 Replication-Controller 。

Deployments 开始逐渐取代 Replication-Controller/ Rolling-Update 程序。 Deployments 是声明性的，这一点很厉害：就是你不必告诉集群要做什么，你只要声明你想要什么功能，然后集群就会调度所有需要的东西来将它自己呈现出理想状态。不需要你自己计算唯一值，要更新的时候也不再需要自己去寻找存在的配置。

官方介绍指南使用 kubectl create 创建部署，使用 kubectl apply 更新部署。但从我的个人经验来看，你可以在上述两个案例中应用，这就意味着你创建和更新的时候不再需要不同程序。

最后一个很棒的部署功能就是支持回滚。 K8S1.1 中的回滚功能已经通过重新部署旧 Replication-Controller 完成。在 K8S1.2 中，当你创建一个配置的时候，你可以使用记录 Flag 。这样的话，在你需要的任何时候，都会允许你回滚一个配置到目前的版本。

Ⅱ 支持多可用性区域

K8S1.2 版本之前， K8S 最大的缺点之一就是，它缺乏在不同 AZs 上对延展程序的支持。这就意味着你的集群只存活在单个的 AZ 上，万一这个 AZ 出什么故障，你会失去你整个的集群。要 handle 这些故障的唯一办法就是管理多个集群，但是这么做的开销是在无法负担。

K8S1.2 带来了 Multi-AZ 的全力支持。你可以很容易在任何 AZ 生成节点，调度器能充分意识到不同节点调度你的 pods 。

虽然在这领域这是一个显著的改进，但是 Multi-AZ 支持并不适用于 K8S 及其组件。你的集群仍然存在于一个 AZ ，如果这个 AZ 停机你会陷入一种古怪的状态：集群功能齐全但集群不会，这就意味着不能 handle 部署操作等等。

K8S1.2 带来完全支持 Multi-AZ 的功能。你可以轻松的在任意 AZ 上复活，而且调度器调度你的 pods 到不同的节点上的时候对此是了解的。

这个领域中，这是一个了不起的改进，因为支持 Multi-AZ 不仅应用于 K8S master 和它的组件。你的 Master 在单个的 AZ 上面也是运行的，如果 AZ 出了故障，你将会陷入一个不好的状态：集群全都会起作用，但是 master 却不会，这就意味着想配置这样的操作处理不了。

Ⅲ ConfigMaps & secrets 作为环境变量

K8S1.1 有一个通过 Secrets 存储配置内置选项。但是仍然推荐使用 Secrets 来存储敏感数据， ConfigMap 允许通过更加直接方便的方式来允许我们存储不敏感数据配置。

K8S1.2 中一个很棒的调整就是， Secrets 和 ConfigMap 不仅可以作为数据卷（ K8S1.1 中的唯一选择）使用，而且对于你的定义文件来说，还可以作为环境变量。比加载数据卷和在应用程序上读取文件更加方便，就是为了获取一个简单的配置项目。

Ⅳ Daemon-Sets

拥有一个 K8S 集群有时让我们忘记我们有集群中还有节点。我们创建容器，但是大多数时候我们甚至不知道他们跑在哪个节点上。

虽然也有那么几次当我们需要处理一些与节点相关的任务的时候是知道的。一个例子就是，一个应用程序从节点收集语句，然后传送他们到一些度量服务器。另一个例子就是，从所有运行在节点上的容器那里收集所有日志，然后发送到我们的登录系统。这些例子中，我们需要单个的容器在运行每个节点。

K8S1.1 仅仅只是提供给我们静态 pods 来完成这个目的。为了定义一个静态 pod ，我们可能不得不在每个节点上的特定文件夹下用 pod 定义。这显然很不方便因为：

1 、如果我们想要添加静态 pods ，我们就不得不警告在集群上运行的每个节点。

2 、静态 pods 在本地被 kubelet 管理，所以我们无法查询 API ，也无法对他们进行任何别的操作。

K8S1.2 介绍了 Daemon-Sets ，它会提供给我们一个更加方便的方式在每个节点上运行一个 pod 。 Daemon-Sets 里面的 pods 是可视的，就好像系统里的其他 pod 一样。你可以删除一个 Daemon-Set ，然后通过 API 创建你想要的 Daemon-Sets 。不需要改变节点上的文件了。

Ⅴ 集群大小和性能

集群大小对于一个公司来说是一个很重要的问题，它有着决定核心基础设施的权利。我们此刻永远也不会知道我们会在一年后规模变得多大，但是我们需要百分之百确定的是，我们现在选择的工具以后不会限制我们。

官方新发布的 1.2 版本每个集群支持 1000 个节点，同时支持 30000 个 pod 同时运行。

然而这些数字可能是好的也可能是坏的（取决于你的主观意愿），查看团队运行到了什么进程是鼓舞人心的， 1.2 相比 1.1 发布版已经有了一个 X10 的缩放改善。

期待在 1.3 上看到一个更高的数字。

Ⅵ Jobs

Jobs 允许你运行 pods ，以及成功完成一定数量的 pods 。在 K8S1.1 中，我们可以创建裸 pods （没有 Replication-Controller ），但是这些 pods 根本不能保证完成。例如，运行有 pod 的节点在执行过程中重启， pod 就不会在另一个节点被重启。通过验证我们完成的 job ，上述的情况确认不会发生。

虽然这不是一个改变世界的功能，但是绝对是一个有用的功能！

Ⅶ 项目进程

除了上文描述的功能和改进，你很容易觉察到 1.1 版本后的巨大进步。每个 issue 就是几个小时的问题，而且由拥有者优先化。等待良久的功能即将实现。越来越多的贡献者正在加入这个大派对，通过提交代码帮助改善这个项目，扩大以及讨论这些 issue 。这大概就是我最喜欢使用的 OSS 项目之一了。

原文链接： https://engineering.nanit.com/7-reasons-to-choose-kubernetes-1-2-as-your-docker-orchestration-framework-363cbddf5c9#.ycnuik8j3?sukey=fa67fe3435f5c4beeea80f41b1bb7b3abc3ae53a17d5d55740517fc2f726566323152f6c738af0d45329b7621ab12025