Kubernetes不会重蹈OpenStack的炒作周期覆辙的七个理由

分布式实验室 · 公众号 · 后端 · 2017-12-26 07:45

正文

Kubernetes是否存在像OpenStack一样的炒作周期的危险？没有，完全没有！我有七个理由断定Kubernetes在交付之前不会滑向炒作的深渊。

作为一个产业，我们喜欢玩“红蓝大对抗”的游戏。我确信创建一个OpenStack vs Kubernetes的搞笑图片是一个天大的错误。 OpenStack是有关基础设施的，而Kubernetes是关于应用程序交付的。如果它们是应该高度协同的，而不是相互竞争的，那么为什么我们要继续回到“对抗”的叙述呢？

上周KubeCon公布了有关Kubernetes的相关事件、社区和供应商的爆炸性增长的明确证据——这也是我一直标注为“尖峰时刻”的东西。虽然有一个引人注目的愿望，即将这一事件与过去几年OpenStack的相关事件进行比较，但我认为这是一个欺骗性的对比。它们与开源工作类似，因为这两个项目都在快速增长，由大厂商推动并充满希望；然而，它们有着不同的市场动力，因为它们服务于不同的用户群体。

Kubernetes领导层和管理Kubernetes的云原生计算基金会（CNCF）正在根据自己的需求以及观察其它项目比如OpenStack制定不同的战略选择。

任何快速发展、超大规模的开源项目都会面临管理上的挑战，甚至吓跑每个参与者。从这个意义上说，相似之处是显而易见的：随着出现越来越多的不同利益方，维护贡献者和保护项目的完整性是很困难的。我曾在OpenStack董事会任职四年（我被投票提名为2018年的职位）；作为帮助引导该项目的活跃领导者，我在这些问题上的立场是有据可查[1]的。

让我们来探讨一下Kubernetes不会重蹈OpenStack历史的七个相互关联的理由。

1. 关注应用程序而不是基础设施

“云原生Kubernetes”听起来像一个矛盾，这是一个非常相关的点。所有的CNCF项目都聚焦于应用交付。这意味着他们搞了一个非常不同的“堆叠式”用户社区。这些用户能够利用Amazon Web Services、Google Cloud Engine或Azure等通用基础设施作为起点，因此在项目启动时的运维差异极小。这意味着新用户将专注于如何使用而不是如何安装。

最终，对于OpenStack来说不可避免的安装和运维挑战会造成采用方面的摩擦。我了解如何亲自将OpenStack基础设施调试到正确状态方面的挑战（请参阅“Crowbar[2]”）。我们努力创建的可重复的底层经验帮助我们通向了Digtal Rebar[3] API驱动的配置技术，这是RackN[4]的核心。任何直接依赖物理基础设施的东西（最终都是这样做的）都会为社区构建增加很大的复杂性。

2. 通过代码拥抱的API以及早期的一致性

Kubernetes能够利用OpenStack互操作性工作（请参阅我的DefCore工作[5]）来快速建立经过认证的API标记。虽然这还处于初期，但却发出了一个明确的市场信号——供应商期待以可移植的方式遵守API。这有助于建立用户信心和供应商参与度。反过来，这些举措为一个活跃的生态系统创建了可访问的市场，从而吸引更多的用户。

我也相信Kubernetes更愿意通过代码拥抱API。在我看来，一个（不幸的是）在OpenStack社区的妥协是要求所有的OpenStack供应商使用相同的代码库。我不认为这两个项目都有分叉的危险；然而，当需要特定的代码时，它会向参与者发送错误的消息——API是用户的交互点，而不是代码。也就是说，我认为Kubernetes会从通过使用单一的语言——Golang而从中获益，而不是有多个分发源。

3. Kubernetes是一个生态系统，而不是一个单体应用

Kubernetes中的长者决心保持项目小而专注。他们乐于使用CNCF作为Kubernetes生态圈相关项目的安全阀。典型的设计讨论开始是固执己见的（只是Docker和GCE/AWS），然后在模式和范围扩展的时候提出通用的API。这意味着随着时间的推移，项目会变得越来越小并解耦。

大型项目都面临着增加功能范围的巨大压力。这就是为什么OpenStack不断添加诸如数据库、负载均衡器、UX和编排系统等“半核心”服务的原因。虽然对许多用户来说和谐是必不可少的服务，但是如果管理层协调一致的话，他们也会创造一个紧密耦合的单体应用。这些功能虽然关键，但它们不是基础设施API的核心。解耦它们虽然会限制API的融合，但它构建了一个关键的生态系统，并使它们能够更快地进行创新。

4. 没有大帐篷，而是一个项目的停车场聚会

CNCF松散的治理方法可能会让人困惑，因为围绕他们如何为会员选择项目似乎是没有什么组织或主题的（收听我们最近的播客[6]）。他们不需要项目或通用基础设施之间的协作；但是，这些项目确实有一个共享的架构方法。这种轻量级治理（自我描述为“最小可行治理”）并不会在社区中创造“内外”的思想，因为项目整合在一起的期望很低。相反，它们经常被统一，但并不总是包含在应用程序套件中。

与OpenStack弃用的“大帐篷[7]”实验相比，这种方法非常有创新性。它们是如何不同的呢？ Kubernetes和其它CNCF项目之间没有产生混淆。这意味着用户不会期望项目之间的整合（请参阅开放基础设施文章[8]）。

5. 丰富的Kubernetes即服务

Kubernetes从早期就开始提供“即服务”产品，而提供商的数量也在迅速增长。服务提供商在这个领域活跃起来有几个非常积极的好处。首先，它们使用户更容易采用。其次，他们非常关心代码库的规模和可操作性。第三，也是最关键的是，他们推动API保持一致性和可移植性。这些实例为社区提供了“参考”实现，鼓励他们进行协调，以便他们能够就增值功能进行竞争。

这些即服务产品也存在一些风险，比如黑箱操作以及隐藏代码分叉，这对OpenStack公有云来说是一个巨大的挑战，并且这一问题因为私有云供应商的慷慨解囊而变得更加复杂。由于aaS供应商出现速度较慢且难以标准化，因此OpenStack用户发现自己处于定制安装状态，而不是构建可移植的基础设施，不过这种趋势正在缓慢扭转。

6. 强有力的管理

Kubernetes受益于Google的强大管理。在项目关键的构建阶段，Google的顶尖人才、设计验证和财务投资推动了Kubernetes的进展。 Google不直接与RedHat、CoreOS、IBM或三星等公司竞争的实际情况也使得他们可以安全地加入，更重要的是认可这个项目。单一供应商的影响力太大是一个风险，然而，Google也发出了正确的信号，即让其关键领导人退出。

虽然OpenStack由Rackspace和NASA发起，但管理程度受一开始设计的诸多限制。作为戴尔的一员，我加入了这个团队，迅速将社区推向了多供应商领域。当协作环境允许时，这使得项目在关键的孵化阶段发展壮大。不过回想起来，我希望我们更专注于技术。

7. 竞争对手

最后，Kubernetes可以从相对于其它容器调度系统较晚的发布时间中受益， Docker、Mesos、Rancher、Apcera、Cloud Foundry和其它几个（有谁还记得StackEngine ？！）最初有更完整的产品线。我记得当Docker Swarm（v0.12版本）通过与Docker Engine集成发布引起业界轰动时，Kubernetes只被视为一个只有不温不火的商业支持的弱者（直到Red Hat发布OpenShift）。这个稳健的市场策略使项目在没有太多聚光灯（目标？）的情况下成熟起来。

相比之下，OpenStack似乎已经完全成型，并且具有比预期更大的风险投资营销预算。确实存在合理的公开的竞争对手（CloudStack、Eucalyptus和OpenNebula），但围绕该项目的厂商炒作也积极地定位了OpenStack（是的，我在这里很有罪过）。这毁掉了技术路线和良好愿望。现在Kubernetes似乎已经赢得了这场容器调度的战争，蜜月已经结束了。

最后

没有一个正确的方法来管理一个开源项目（鸣谢安娜·卡列尼娜[9]）。我们所能希望的最好方式就是我们所做的好的选择胜过那些糟糕的。虽然这篇文章重点聚焦于OpenStack的挑战，但是我们也做出了很多很好的选择，对于新的开放基础设施方向我感到乐观。 Kubernetes正在根据这些选择和自己的需求编织自己的路径。迄今为止，我支持这些选择。我希望我上面的这七点理由能够帮助你更深入地思考这条路线——我想听听你们的关于对我所做的正确的事以及我错过了什么的一些看法。