Tiny Guo 译 分布式实验室
如果你们公司已经准备全面使用Kubernetes编排管理器，而你为了方便部署正在找寻一个包管理工具，那么你可能会倾向于选择Helm，一个正在云原生计算基金会（CNCF）孵化的开源项目。
你有可能还希望从推广容器的公司了解Docker Compose，或者Draft——一个微软项目，由开发Helm的同一帮人开发，或者还可能是Open Service Broker API，Habitat，或其他17种不同的开源包管理器。CNCF在其Landscape[1]网页上列举了所有这些内容，包括272个其他的云原生开源项目。同时，这份清单每周都会追加更新。
有人会把这种过多的选择称为chaos（混乱），也有人称之为新一波创新。不管怎么说，围绕Kubernetes发展而成的生态系统已经展示了其优势但也带来了混乱。对于那些已经准备将宝压在Kubernetes上的公司，如何在众多的可用扩展和应用程序接口之间做出一个明智的选择，正成为它们面临的最大挑战之一。
IBM云平台全球副总裁兼首席技术官Jason McGee说：“这个圈子的活动多到令人惊讶，但我并不羡慕普通企业试图去收集所有这些东西。”Jason McGee在西雅图举行的KubeCon会议上发表主题演讲，共有8,000名技术爱好者聚集在一起，学习虚拟化技术之后最热门的和数据中心相关的技术。
Kubernetes是一个云原生平台，它正在颠覆应用程序的开发方式。该软件由谷歌（Google LLC）创建并且于四年前发布为开源软件。它迅速成为部署和管理大量容器类软件的主流平台，这些软件是自包含的，即包含了应用程序需要跨环境运行时的所有代码和依赖包。
几乎所有的计算机和云基础设施公司都以原生形式采用了Kubernetes，这是前所未有的壮举。这其中的一个重要的因素是，一个单独的可参照的平台催生了一个庞大的开发者社区。他们正在扩展Kubernetes在监控，日志，安全及存储等领域的核心能力。
CNCF的Landscape对云开发者而言就像一个应用商店。“拥有强大的第三方生态系统是彭博资讯选择将其大部分开发业务转移到Kubernetes的重要原因之一。”财经新闻和分析公司的数据分析和基础架构负责人Steven Bower表示，“并非所有应用都要在Kubernetes中，你可以使用容器网络接口（CNI）混搭和集成不同项目的不同组件。”他指的是Kubernetes的原生规范中利用网络插件为容器服务。
“Kubernetes的生态系统异常强大，因为市场意识到Kubernetes的威力。”Codefresh公司专门销售针对Kubernetes的持续交付平台，其首席布道者Dan Garfield表示，“要来一个云上通用的API吗？好极了。”
但有些专家警告说，现在的生态系统有点像一个狂野的西部片，许多项目都在争取成为焦点，但几乎没有明确的领导者，组织一旦做出错误的选择可能会导致在未来几年内都将陷入耗时的迁移过程。
“现在采用Kubernetes的企业正行走在开源项目演进的雷区。” SiliconANGLE姐妹市场研究公司Wikibon的首席分析师James Kobielus说，“他们总体上仍然没有达到一个成熟的，与供应商无关的产品栈，可以解决各种生产级的企业应用案例。”
生态系统迅猛发展的其中一个原因是，Kubernetes的所有权从Google转移到了社区手中。谷歌领导者从经验中得知，如果试图控制该项目将会阻止竞争对手做出贡献而阻碍该平台的发展。他们希望避免出现分裂，因为分裂已经给其他开源项目造成了破坏。举个例子：OpenStack，一个IaaS（基础设施即服务）平台，据说该阵营内成员之间的内斗和众多的衍生版本导致其未能兑现承诺。
“为了赢得更广阔的世界，我们必须学会放手并且相信我们留下的任何空白都干干净净，以便他人尽情发挥。”谷歌的高级软件工程师兼Kubernetes的主要开发人员之一Tim Hockin说，“流于形式的表面工作必须有限度，生态系统一定要茁壮发展。”
“如果谷歌仅仅只开源了Kubernetes，”Gartner公司的研究主管Gregg Siegfried表示，“它无法拥有今天的影响力。”
因此诞生了CNCF。2014年，当谷歌准备将Kubernetes开源时，它选择绕过Apache基金会，该基金会已经在培育一个名为Mesos的竞争性项目，而与Linux基金会合作创建CNCF作为一个新的管理机构管理云原生软件。Linux基金会在支持单个Linux内核方面的记录是Google希望在Kubernetes上看到的发展模式。
开源管理机构一直在和经常产生利益冲突的贡献者们作斗争，特别是那些销售相关产品和服务的贡献者们。“在创新与稳定之间绷着一根弦，”福瑞斯特咨询公司副总裁兼首席分析师Dave Bartoletti表示，“这些公司必须实现货币化，而为了货币化一些事物，它必须是稳定的。”
Kubernetes的开发人员希望稳定核心部分并促进生态系统的创新。CNCF的任务是围绕一个Kubernetes代码库将整个行业的竞争对手聚集到一起。它借鉴Linux playbook，制定了一个Kubernetes认证一致性计划，以审核Kubernetes发行版之间的连续性。
到目前为止，90个包和托管版的Kubernetes发行版[2]已获得认证，确保不会出现所谓“分支”的差异。CNCF还要求成员将他们创建的任何补丁都提交给社区以便参考，从而降低无意中出现分支的风险。
之后，CNCF打破了它自有的方式，接受和培育起开源项目的生态系统。开源基金会的职责之一就是挑选竞争的获胜者，通过指派特定的项目接受服务，包括项目管理、支持、文档推广及其他资源，用来帮助那些项目取得成果。这些项目被称为“孵化”，成熟以后就会“毕业”。
CNCF的创始人认为Apache的政策太过严苛并且过于关注开发人员。他们想要一种更具包容性的方法。Patrick O'Reilly表示 “我们希望抛开Apache项目的所有政策和流程，重新开始。”他是CNCF的创始人之一，现在是Get Cloud Native公司的首席执行官，Get Cloud Native公司专注于帮助企业迁移到云平台。
该基金会降低了项目转变成孵化类项目的门槛，并将大部分决策权下放给了项目所有者。O'Reilly说：“CNCF能让那些通常不爱说话的人说话。我不是说这是最好的方法，但它是我们现在拥有的最好的方法。”
现在，CNCF的技术监督委员会是决定孵化新项目的唯一仲裁者。它与理事会分开，理事会的成员包括供应商和其他商业利益相关方。该基金会还要求每一个项目都有一个中立的治理流程，用来最大程度的减少来自行业的压力。
Gartner的Siegfried说：“Apache社区的流程稍显笨拙，并且不允许快速演进和多样化的视角。而CNCF则培养和鼓励管理社区流程。”
事实上，有些人认为CNCF是未来如何处理开源项目的典范。“本质上，它正在为微服务这一新世界，重新打造应用程序开发平台。”Wikibon的Kobielus说道，“这是计算机历史上史无前例的一项雄心勃勃的计划。”
但是，较少规则带来的缺点是充满不确定性。对于平衡创新和稳定性方面，CNCF的方法是否一定优于其他方法，这点仍然有待商榷。到目前为止，除Kubernetes之外，只有两个项目已经毕业：一个是Envoy，一个简化网络服务的代理服务器。另一个是Prometheus，一个监控平台。
所以它仍处于早期阶段，项目需要数年才能孵化。目前，“Kubernetes生态系统已成为众多供应商角逐发行版和托管云版的一个混乱领域。”Kobielus说，“而以谷歌开发的Kubernetes为中心，不断增加的开源项目，更是乱上加乱。”
出现各种选项百花齐放的局面，这里有一些刻意的因素。谷歌向社区发布Kubernetes的目标之一是随着时间的推移，将更多的功能转移到扩展中，削减核心代码库。Kubernetes本身已经“与我们发布它时完全不同。”Hocking说，“我们希望把更多的功能从核心中剔除。”
CNCF的首席技术官Chris Aniszczyk表示，该基金会正在努力坚守这一原则。他在本周接受采访时表示，“Kubernetes一直专注于将功能从核心中剔除，以尽可能地实现其扩展性。”
但对于那些想要追随Kubernetes的组织而言，选择的多样性可能会带来一些问题。尤其是那些大型企业，这点更加令人担忧，“他们需要一个可以遵循的合法合规的要求或者内部的标准。” DivvyCloud公司首席执行官Brian Johnson表示，“大多数生态系统中的项目，在这方面还没有明确的技术控制或最佳实践的流程。”DivvyCloud公司是一家提供政策驱动的云安全和合规公司。
挑选胜出的项目可以使组织更好地利用社区的研发能力，因为成功的项目意味着下一轮创新。“开源世界中有一股吸收所有的能量的动力。”IBM的McGee说。“你会想要与之合作。”
随着一些孵化类项目的毕业和其他一些项目的淘汰，Kubernetes生态系统不再是“你要自己用一篮子工具打造属于你的东西。”齐格弗里德说，“它将提供一个完整的集成。”
有证据表明Kubernetes生态系统正在进行整合。本周基于一项对GitHub仓库的分析，Sourced Technologies S.L.表示“Kubernetes项目核心部分的提交速度似乎有所放缓。”
“我已经看到正在发生的第一轮整合。”IBM的McGee说，“但我们仍处于如何整合各部分的生态系统创建阶段。”
经历这类周期也不是什么新鲜事。在业界选择使用Linux之前，曾经有超过20个版本的Unix。Hadoop大数据生态系统在早期也异常复杂，直到软件供应商和云计算公司介入后，简化了部署和集成过程。Johnson说：“最有可能的结果是将会有5到10个主流Kubernetes框架，早期试用这些框架的企业将测试和验证这些框架。”
在很大程度上，采用Kubernetes的速度加快了其成熟的过程。O'Reilly说：“一旦你让银行进入，人们不再希望发生重大变化。”
IT的选择
那么信息技术经理该如何在此期间做出决策呢？Forrester的Bartoletti认为，对大多数公司而言，这都不是问题。
“企业首先要清楚他们是平台的构建者，平台的运营者还是平台的消费者。”他说，“这个选择决定了你该如何分配资源。”
Bartoletti将平台的构建者定义为业务主要依赖于在Kubernetes平台上创建应用程序的公司。对他们而言，在生态系统方面做出正确的选择至关重要。平台的运营者更愿意托管他们自己的Kubernetes实例，且不认为该平台具有战略意义。平台的消费者只想要一个可用的平台，不会特别关心它的出处。
“如果要建一个旅行预订系统，那么根据所建平台的差异性进行取舍，这点尤为重要。”Bartoletti说，“但一般的企业可能不需要加入所有社区。”
平台的运营者可通过与那些在生态系统活跃度很高的商业Kubernetes供应商合作（例如IBM，Red Hat公司或Pivotal软件公司），以防止在选型时陷入困境。“如果Pivotal为您提供了很好的服务，那么就没有理由改变。”他说，“因为Pivotal的工作就是保证它们正常工作。”
对于平台的消费者来说，最好选一家主流的公有云提供商，可提供全面可控的服务并负责保持客户当前的状态。
专家认为，虽然目前的生态系统让人眼花缭乱，但平台的消费者也不能只充当旁观者。开源项目的优点之一是它们基于标准工具集，可以适应Landscape的变化。例如，Docker公司最初选择自己的Swarm编排工具而不是Kubernetes，但这并没有阻止它之后与Kubernetes集成，而Swarm仍然是一个可选项。
负责任的开源供应商不会做出死板的决定。“有可能[亚马逊网络服务公司]将来会从Lambda转移到另一个Serverless平台，但人们会后悔使用Lambda吗？”Bartoletti说，“我的客户们都不会后悔。”
基于这一事实，IT经理们应该可以减少些对他们所做决定的担忧：在开源的世界里，即使选错了也能得到令人满意的结果。
相关链接：
https://landscape.cncf.io/cncf=hosted,graduated,incubating,sandbox,member,no&license=open-source
https://www.cncf.io/certification/software-conformance/#logos
原文链接：https://siliconangle.com/2018/12/13/kubernetes-sprawling-ecosystem-offers-plenty-choice-risk/