如果你们公司已经准备全面使用 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 表示,"它无法拥有今天的影响力."
寻道 Linux 之路
因此诞生了 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
来源: http://cloud.51cto.com/art/201901/590559.htm