细数实现容器可扩展性的多种途径

[Mrexamo]

一些企业已经进军新兴的容器虚拟化领域，但企业或开发者已经有越来越多的担心，这项技术可能并不像宣传的那样有效，针对先进的应用程序和微服务——至少目前还没有。

目前，最大的问题是可扩展性。 Docker ，一家领先的容器开发公司，毫不掩饰自己对更高可扩展性的欲望，为此，他们首先需要解决的是在大量的容器之间实现更高效的网络通讯。目前，该公司通过与 Red Hat 、亚马逊和 IBM 这样的公司联合开发项目，提供了大量的编排和管理工具。

该公司还与谷歌及其 Kubernetes 容器管理系统合作密切，但正如 Platform 的 Timothy Prickett Morgan 指出的那样，即使 Kubernetes 缺乏可扩展性计，但是至少这是谷歌的标准。典型的谷歌集群，大约由公司的 Borg controller 监视的 100000 机器，它本身可以 scale 超过 10000 个节点。 Kubernetes 封顶 100 节点,每个节点 30 container pod ，这勉强能够支持一个中等公司的需求。事实上，谷歌可能更喜欢这样，以免给潜在竞争对手一个现成的解决方案来实现谷歌的规模。

不过，企业希望部署容器会规模高于一切，否则为什么要使用容器吗？为此，很多第三方开发者构建他们自己的解决方案。

Nexenta ，最近添加容器支持其 NexentaEdge 软件定义存储解决方案，它提供一个利用原生云应用程序的容器。随着新兴有状态的云应用和微服务开始解决企业级的工作负载，需要集成的持久性存储正在增长。 Nexenta 表示，当管理的容器增加时，它可以通过提供无缝存储集成管理满足这种需求和维护有效的资源消耗。

与此同时，一家名为 Univa 的公司增加了 Docker 支持 Grid Engine 工作负载和资源管理器。这将使企业不仅管理大规模的容器，然后在异构应用程序和基础设施环境中融合到现有的工作负载。 Grid Engine 处理调度、资源分配、优先级和其他任务，需要把容器从测试环境带到生产环境中。作为一个 multi-infrastructure ， multi-OS 平台，首先， Grid Engine 的优势在于跨不同资源扩展成千上万的应用程序和应用程序框架，使企业可以在可用的基础设施上扩展容器环境。

同时， Mesosphere 也正在其 Datacenter Operating System （ DCOS ）上通过合并数据中心功能寻求解决容器扩展问题。该公司最近添加了 Marathon 初始化和控制系统，其支持跨集群部署 Docker 。系统通过集成 Kubernetes 来进行主机管理，还添加了许多本土资源和配置管理等功能来平衡容器大小和其他参数对可用资源的消耗。反过来，这允许容器环境 to scale 成千上万的节点。作为 Apache Mesos 框架的一部分，这个系统的目的是支持大数据，物联网和其他大型的工作负载。

需求是创造之母，在这种情况下，需求在容器环境中对于 scale 是至关重要的。 Docker 这样的公司无疑急于向市场提供他们替代的虚拟化解决方案，但是这样做没有解决现代数据架构的关键方面：一切需要 scale 或是 DOA 。而 Docker 正在解决这样的问题。

本文由时速云工程师丁麒伟编译，原文链接：细数实现容器可扩展性的多种途径