Kubernetes规避类似OpenStack的炒作周期的七宗罪

2017-12-20 20:00:00 Tong Leion 翻译 云技术实践

作者简介:Rob Hirschfeld是RackN的首席执行官兼联合创始人,RackN 为以容器为中心的数据中心提供编排软件。从早期的ESX测试版到OpenStack基金会董事会的四届任期,他在云计算和基础架构领域已经工作了将近15年。

 

Kubernetes 是否和 OpenStack 一样存在炒作周期(又叫:技术成熟度曲线)的风险?不。于此我们很确信!而且我有七个恰当理由来解释为何交付前不会存在大肆炒作。


对一个行业来说,我们喜欢玩 “红 vs 蓝” 的游戏。我相信创造一个 OpenStack vs Kubernetes 的模仿传递行为是个错误的做法。 OpenStack 是关于基础设施的,而 Kubernetes 有关 应用交付。如果二者需要高效协同而不是竞争,那么我们为什么还要继续回到 “vs” 的陈述方式呢?


上周的 KubeCon 大会充斥着 Kubernetes 相关的事件、团体和厂商爆炸式增长的清晰明了的证据——我对此贴了个标签“巅峰浪潮(peak bandwagon)”。虽然我强烈希望将此事件与过去几年的 OpenStack 巅峰事件做对比,但我认为那将会是一场虚假的比较。二者对开源的贡献相似因为他们都增长迅速、大厂商驱动并且大有前景;然而他们的市场动向不同因为他们服务于差异巨大的用户群体。


Kubernetes领导层和管理Kubernetes 的云原生计算基金会(CNCF)一直在根据他们需求及同时关注类似 OpenStack 的项目的发展做不同的战略选择。

 

任何快速发展、超大规模的开源项目都会面临管理上的挑战,吓跑每个人。从这个意义上来说,相似之处很明显;随着越来越多不同利益出现,很难同时做到维护利益者和保持项目完整性。我曾在OpenStack董事会任职四届(并且被提名为2018年的职位 - 所以请投票!); 作为帮助指导项目的积极领导者,我在这些问题上的立场是有据可查的


让我们来探索一下 Kubernetes 不会重蹈 OpenStack 的覆辙的相互关联的七种方式。


1.专注应用而非基础设施

“云原生 Kubernetes”听起来像是一个矛盾的修辞,但它却是一个非常切题的点。CNCF 的所有项目都是以应用交付为重点的。也就是说他们搞了一个 “向上堆叠式” 用户社区。这些用户能够充分利用 Amazon Web Services,Google Cloud EngineAzure 等通用基础架构作为起点,因此起始时操作差异很小。这意味着新用户将专注于使用而不是安装。


最终,OpenStack不可避免的安装和操作挑战会对用户决定采用与否造成阻力。我清楚亲手构建 OpenStack 基础架构的挑战之大(请参阅“ Crowbar ”)。我们创造可重复的底层体验的艰难努力促成了成为 RackN 的核心的 Digital Rebar API 驱动供应技术。任何直接依赖物理基础设施的东西(最终一切都会如此)都会极大增加社区建设的复杂度。


2. API Over Code 和早期一致性

Kubernetes 能够充分利用 OpenStack 协同工作能力(请参阅 my DefCore efforts)来快速建立经过认证的 API 标记。虽然刚刚起步,它发出了一个明了的市场信号,厂商期望以便携的方式重视 API。这有助于建立用户信心和厂商参与。反过来,这些又为活跃的生态系统创造一个可定位的市场以吸引更多用户。


我也相信 Kubernetes 更愿意拥抱 API over code。OpenStack 社区要求所有厂商使用相同的代码库在我看来是一个不幸的妥协。我不认为这两个项目有分叉的危险; 然而,当需要特定的代码时,它向参与者发送错误的消息——API是用户的交互点,而不是代码。也就是说,我认为 Kubernetes 是由于具有单个开发语言,Golang,而且没有多个分发源。


3. Kubernetes 是个生态系统,并不是僵化的铁板一块

Kubernetes 的前辈们决心保持项目小而专注。他们乐于将 CNCF 作为 Kubernetes 系相关项目的一个安全阀。典型的设计讨论是武断开启的(仅有 Docker 和 GCE/AWS),然后拉出通用 API 作为模型,继而范围扩大。这意味着随着时间推移项目逐渐变的更小而独立。


大项目面临增加功能范围的巨大压力。这就是为什么 OpenStack 不断添加诸如数据库,负载均衡器,UX 和编排等“半核心”服务项目的原因。虽然对很多用户来说这些事必要的服务,但是如果管理协调一致的话他们也能创造出一个密切耦合的系统。这些是关键功能,但不是基础设施 API 的核心功能。将其解耦限制了 API 的聚合度,但是能建立一个关键生态系统并允许快速创新。


4. 不是大帐篷,而是项目的“车尾大聚餐”

CNCF 松散的治理方式可能会令人困惑,因为他们选择成为会员的项目似乎没有什么组织或主题(请听听我们最近的播客)。他们不需要项目或通用基础设施之间的协作; 但是,这些项目确实有一个共享的架构方法。这种轻量级治理(自我描述为“最小可行治理”)并不会在社区中创建“内外”思维,因为对项目整合在一起的期望很低。相反,它们经常被统一起来,但并不总是包含在应用程序堆栈中。


与OpenStack过时的 “大帐篷” 实验相比,这种方法富有创新性。他们之间有什么不同?Kubernetes和其他CNCF项目之间没有产生主打的混淆。这意味着用户不会期望项目之间的整合(请参阅开放式基础架构)。


5. 丰富的 Kubernetes 即服务

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


即服务(as-a-service)产品也存在风险,比如黑盒操作和代码库的隐藏 fork 。这对OpenStack公有云来说是一个巨大的挑战,因私有云厂商的大量加入令其状况变得复杂。由于 aaS 厂商出现速度较慢且难以标准化,因此OpenStack用户发现自己只能定制安装,而不能构建可移植的基础架构。这种趋势目前正在缓慢扭转。

 

6.强有力的管理

Kubernetes 已从 Google 强大的管理中获益。在项目关键的建设势头阶段,Google 的深厚的人才基础,设计验证和财务投资驱动了 Kubernetes 的发展。Google不直接与 Red Hat ,CoreOS,IBM或Samsung 等公司竞争的事实使得他们可以安全地加入进来,更重要的是获得他们对这个项目的认可。然而单个厂商的影响力过大也是一种危险,对此谷歌也给出了正确的信号,它退入幕后并让关键领袖退出。


虽然 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 似乎已经赢得了容器调度器的战争,显然蜜月已经结束了。


结论

并没有一个绝对正确的方式管理开源项目(向 Anna Karenina 脱帽致敬)。我们只能寄望于好的选择能战胜坏的那个。虽然这篇文章重点讨论了 OpenStack 的挑战,但是我们也做过很多好的选择,而且我对于新的开放式基础架构方向感到乐观。Kunernetes 正基于这些选择和它自身需要前行在自己的道路上。迄今为止,我支持这些选择。我希望我的七个关键点能帮助你对此更加深入的思考——我非常希望能听到你的观点。 


译者介绍:

Tong Leion,思科认证工程师,开源技术爱好者,曾运营过OpenStack公有云,目前就职于电信运营商系统集成行业。

 

↓↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读:

高端私有云项目交流群,欢迎加入!

Forrester:混合云评测报告

Gartner:2018年基础设施和运营的十大技术趋势

俄罗斯建立备份DNS系统 将被金砖五国使用(巴西、俄罗斯、印度、中国和南非)

IBM推出新 DNS 服务(9.9.9.9),谷歌(8.8.8.8)要哭了。。。

震撼:AWS放弃XEN 改用KVM作为新的虚拟化引擎

Red Hat开始将它的OpenStack平台移动到容器

向云上迁移数据时如何避免停机和中断

如何从传统IT技能转型进入云计算

云管理平台实践指南