转载

容器编排器下一步还要做什么

Docker 1.12横空出世，想必你应该会停下手上的活，马上体验下它的新的编排特性，并且与其他编排器作对比。然而这仅仅是容器部署与管理这种复杂的系统的时代的开始。

在分布式系统的易用性和可靠性这方面，对于我们每一个人而言，还有很多需要改进的地方，期待在接下来的几年里能看到更多的改进。随着分布式系统的演进，编排器将会在系统引导、维护性、可靠性以及安全性方面提供更好的体验。接下来是几个我觉得从中等或大型规模集群这些基础设施的角度来看都非常乐于看到的特性点：

超级稳定/更好的容错性。当整个区域的机器都瘫掉，或者网络拓扑被意外的改变了，或者因为你还为上个星期的《权利的游戏》剧集而分心，导致你在集群节点上执行了一个错误的操作，在这些状态下随便拿出一个节点，节点上面的系统和服务、任务都能够正常运作。在这种情况下，期待的状态是有用的，但仍然存在一些当前系统都还没有处理的关于灾难恢复的细节。比如，失去了大多数管理集群状态的节点（在基于冗余机制来保持一致性的系统中也就无法达到期望的节点数量）会使得集群在没有人工干预的情况下无法实现恢复，因为没有迁移或重新调度容器的动作可执行。

去中心化的镜像管理。镜像可以在无单点故障的点对点环境中共享。

人工智能辅助以及资源感知的编排与布局。系统可以利用细粒度的启发式算法来调度任务，同时可以“记住”集群内被经常调度的资源类型（网络、内存以及CPU密集的），以此达到资源利用与调度的优化。

免协调，无主控的协议。一个节点在系统为它分配角色之前仅仅是一个节点，之后它仍然可以选择一个领导者或者为节点安排指定的角色以完成特定的任务，但是这个协议以及其状态是完全分布式的。调度服务以通过多个不同的路径，该任务应该由领导者完成，或者所有服务都经过一个经过优化的并且根据概率方法来分布式预先分配的路径（点对点预定和路径管理）。这样就可以在 领导者 当机且不能恢复的时候，保证机器故障不会影响集群中的大多数任务。此时集群可能处于腐烂状态，但最终会慢慢恢复并且会修正错误和出错的地方。

基于预测的重新调度以及服务迁移。系统可以预测到某些机器比其他机器更容易出问题，这得归功于集群的运行日志以及运行数据。系统同时可以根据网络流量模型来对工作载荷进行迁移，以实现在服务高峰时间之外缩减集群的规模。

能源效率。集群管理器能感知集群的能源消耗以及在它之上运行的任务，它尽量通过优化部署位置以及任务迁移来降低整体能耗，而这个过程对业务是无中断的。

我想这里反复提及的内容是 容错性以及可靠性 ，我们在创建一个可以处理一种全新的故障类型和人为错误的弹性系统时可以做的更好。其他那些看起来毫无相关的技术像人工智能在这方面可以提供很多帮助。另一个方面是 易用性 ，即使现在的编排器变得越来越容易部署和管理，但我们仍然可以做的更好以达到这样的效果：你仅需要下载一个二进制文件，然后指向一个已存在的机器，那么系统自己就知道该做什么了。编排器正在成为一个在操作系统之上的透明层，可以利用它来构建分布式OS。

原文链接：What could be next for container orchestration?（翻译：唐华新）

译者介绍：

唐华新，华为技术有限公司系统工程师，一直从事网络与协议相关技术研究，目前从事虚拟网络、系统监控、APM领域技术研究与开发，关注Docker、Kubernetes以及Devops等技术。

原文 http://dockone.io/article/1558

正文到此结束