选择Kubernetes作为Docker编排工具的理由有哪些

这篇文章主要介绍"选择Kubernetes作为Docker编排工具的理由有哪些"，在日常操作中，相信很多人在选择Kubernetes作为Docker编排工具的理由有哪些问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"选择Kubernetes作为Docker编排工具的理由有哪些"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

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项目之一了。

到此，关于"选择Kubernetes作为Docker编排工具的理由有哪些"的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！