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

原创 2017年12月26日 00:00:00

?wxfrom=5&wx_lazy=1

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


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


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


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


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


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


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

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


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

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


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

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug


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


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


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

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


5. 丰富的Kubernetes即服务

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


6. 强有力的管理

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


7. 竞争对手

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug

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


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


最后

b2YlTLuGbKDsbJzupnILVFhPtMaRjmvPKYRqTMjibE9pnd8oiawLVrQbOHQe4wBXkBQkzpKCWPKBqWgOLgwccBug


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


相关链接:


  1. http://robhirschfeld.com/

  2. https://robhirschfeld.com/crowbar/

  3. http://rebar.digital/

  4. http://rackn.com/

  5. https://robhirschfeld.com/tag/defcore/

  6. https://www.rackn.com/2017/11/20/podcast-peter-miron-talking-nats-service-edge-cloud-native-foundation/

  7. https://robhirschfeld.com/2014/11/21/big-tent/

  8. https://www.rackn.com/2017/11/14/sirens-open-infrastructure-beacons-openstack-community/

  9. https://en.wikipedia.org/wiki/Anna_Karenina


原文链接:https://thenewstack.io/7-ways-kubenetes-avoids-openstack-like-hype-cycle/


基于Kubernetes的容器云平台实践培训

?


本次培训包含:Kubernetes核心概念;Kubernetes集群的安装配置、运维管理、架构规划;Kubernetes组件、监控、网络;针对于Kubernetes API接口的二次开发;DevOps基本理念;Docker的企业级应用与运维等,点击识别下方二维码加微信好友了解具体培训内容


?


点击阅读原文链接即可报名。
版权声明:本文为博主原创文章,未经博主允许不得转载。

什么是技术炒作周期

研究机构 Gartner 在 1995 年发表了「技术炒作週期」(hype cycle)的理论,这套理论用来分析技术发展趋势与科技产品的生命週期,一项新技术的发展,通常先是萌芽,接著炒作,然后幻灭,...
  • xcjing
  • xcjing
  • 2017年03月04日 10:50
  • 654

OpenStack和Docker不能,Kubernetes和Mesos也不能,ServerLess能决定云计算胜负吗?

还记得在十多年前,SaaS鼻祖SalesForce喊出的口号“No Software”吗?SalesForce在这个口号声中开创了SaaS行业,并成为当今市值460亿美元的SaaS之王。今天谈谈“No...
  • liuliming3000
  • liuliming3000
  • 2016年02月11日 21:17
  • 1203

马云会不会重蹈黄光裕的覆辙

马云高调放风投资绿城的时候,其实意在向恒大施压,意图使许家印卖他一个好价钱。而老江湖宋卫平,恐怕根本想不到自己精明一世,最终沦为了工具被人利用。马云在发布会上否认自己曾经对绿城足球队有兴趣,估计会让宋...
  • duhai
  • duhai
  • 2014年06月07日 09:44
  • 366

虚拟运营商不要重蹈基础运营商覆辙

据媒体报道,虚拟运营商上市以来发展并不理想,甚至至今才仅有二三十万用户,这样的数字与基础运营商每月数百万的增长来比较简直是不值一提。很多人担忧,声势浩大的虚拟运营商们是不是就此沉沦了呢? 通信运...
  • zaguo_8
  • zaguo_8
  • 2014年09月28日 14:51
  • 63

Docker生态会重蹈Hadoop的覆辙吗?

目录 一、Docker的兴起和Hadoop何其相似二、大数据从狂热走向了理性三、Hadoop生态圈的演进四、Docker的生态圈五、Docker公司的战略野心受生态圈狙击六、Docker生态圈的演进七...
  • u012798391
  • u012798391
  • 2016年10月18日 18:12
  • 129

Openstack+Kubernetes+Docker微服务实践之路--弹性扩容

服务上线就要顶的住压力、扛的住考验,不然挨说的还是我们这帮做事的兄弟,还记得上图这个场景吗 老办法是服务集群部署,但总归有个上限,之前跟阿里合作的时候他们有个弹性计算可以通过设置CPU的阀值来动态扩...
  • qkecki24028
  • qkecki24028
  • 2017年01月11日 12:14
  • 1000

容器不会取代OpenStack,但二者如何深度整合?

发表于2015-05-20 18:04| 4760次阅读| 来源《程序员》电子刊| 5 条评论| 作者刘光亚 OpenStackDockerMagnumKilo 摘要:OpenSt...
  • donglynn
  • donglynn
  • 2016年03月16日 09:40
  • 373

马云会不会重蹈黄光裕的覆辙

今天最劲爆的财经新闻莫过于阿里巴巴12亿入股恒大足球,获得其50%股份的事情了。      上午11点11分,阿里董事局主席马云和恒大老板许家印在广州高调召开了新闻发布会,亲述了双方联手的前因后果...
  • u014796599
  • u014796599
  • 2014年06月07日 22:48
  • 502

空谈IT趋势 你将重蹈诺基亚塞班误入歧途覆辙

前言:所有这些被构想、被宣扬、被追捧的趋势,从来不会自动出现在这个世界上,也不是沿着某个既定路线行进就一定能够实现。 “末日”终于过去,我们又可以展望未来了。 正好临近岁末年初,IT预言家们纷纷推...
  • q121365405
  • q121365405
  • 2013年03月04日 00:44
  • 281

Openstack容器项目之Magnum

本文以Newton版本为例。 1.Magnum简介 Magnum项目通过Openstack API能够在Openstack中创建基于容器的服务,但它本身并不直接对容器进行操作,而是通过Kubern...
  • rh57b1f7
  • rh57b1f7
  • 2017年02月14日 12:23
  • 600
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Kubernetes不会重蹈OpenStack的炒作周期覆辙的七个理由
举报原因:
原因补充:

(最多只允许输入30个字)