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

Mrexamo · · 3768 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

一些企业已经进军新兴的容器虚拟化领域,但企业或开发者已经有越来越多的担心,这项技术可能并不像宣传的那样有效,针对先进的应用程序和微服务——至少目前还没有。 目前,最大的问题是可扩展性。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正在解决这样的问题。 本文由时速云工程师丁麒伟编译,转载自时速云。原文链接:[细数实现容器可扩展性的多种途径][1] [1]: http://blog.tenxcloud.com/?p=880

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

3768 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传