为什么Kubernetes能赢得容器之战

本文讲的是为什么Kubernetes能赢得容器之战【编者的话】Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用。今年的调查显示,Kubernetes成为被最广泛使用的编排工具。为什么在编排方面Kubernetes如此受欢迎呢?让我们看Matt Asay如何看待这个问题。

容器的使用在技术中日益广泛使用,尽管不同的编排产品竞争激烈,但是行业中一般都以Kubernetes作为容器的默认编排引擎。

对比诸多编排工具,包含Docker官方的Swarm,我们有必要研究下Kubernetes为何如此受欢迎,尤其是彼此之间复杂度的区别。

像MongoDB和Linux这样流行的开源软件,流行的原因可以归结为社区建设的功劳---例如谷歌研发15年的背后支持。最终,这一独特的卓越工程愿意让别人接手,也是Kubernetes能够成为令人印象深刻的开源项目的原因。

做有内容的社区

从社区的年龄来讲,Kubernetes不占优势。毕竟Kubernetes才两岁而已(从作为开源项目算起),而Apache的Mesos已经推出7年之久。Docker Swarm虽然是比Kubernetes更年轻的项目,但是它的背后是来自于Docker官方容器中心的全方位支持。

然而作为编排工具,对手在社区这一点比起来就显得略微苍白。现在Kubernetes社区在基础云平台的管理下正在不断变得丰富多彩。

  • Kubernetes是活跃在Github中前几名的项目之一:占有在所有项目中排名0.01%的star,而且在所有团队项目活跃度排名第一。
  • 虽然Kubernetes的文档欠佳,但是Kubernetes有自己的Slack和Stack Overflow社区作为补充,帮助解决问题优于其竞争对手。
  • 在LinkedIn上有更专业的Kubernetes专家,相比其他工具,Kubernetes通过LinkedIn为使用者提供了更广阔的解决问题空间。
  • 最明显的是,OpenHub的数据却显示了Apache Mesos正在走向衰落,Docker Swarm增长也开始放缓。从原始社区的贡献来讲,Kubernetes正在迅速增长,从1000+贡献者34000+的提交贡献,远远超过了其他像Mesos竞争对手的四倍之多。

是什么造成了这样疯狂的结果呢?总之一句话,是谷歌,或者是说谷歌的选择开源。虽然其他的每一个编排项目背后都有一个供应商公司在影响着,但是Kubernetes受益于谷歌的不干涉开发,以及比较优秀的原始引擎。

与此同时,Docker拥有实际上的容器标准,Docker也一直在努力构建与Kubernetes一样广泛深入的容器社区。基于以上原因,谷歌的Kelsey Hightower指出,Docker本身在阻止竞争对手进入构建容器标准。

当然,容器不需要任何标准化的输入,但是市场似乎更倾向于更少的权利集中在编排层的容器。由于市场需要一个可行的商业模式,我们期待Docker在ops,hence,编排容器方面的竞争。但是除非公司把Swarm转变为真实的行业标准,这样可能赢得了容器的战争,而会在编排工具的竞争中失败,即使他声称可以提供更好的性能。

谷歌崇拜者

Kubernetes活跃社区的背后是特殊的技术力量驱动。作为谷歌的Borg技术,Kubernetes已经累积了15年的深耕细作的发展和生产实践。这项技术特别好以至于时任谷歌技术基础架构部门领导的Urs Holzle难以置信的反应,当时一些工程师建议建议一个Borg版本并且提议开源。

“所以,让我直说了吧,你可以构建一个外部的Borg任务调度器,这也是我们一个最重要的竞争优势,甚至不谈其他的,重要的问题是要它开源吗?”

工程师使用Borg作为集群管理的工具,其中Gmail,YouTobe,Google Search和其他流行的谷歌服务都是用此工具作为基础框架管理。后来它被内置在谷歌的计算引擎中。但是工程师发现,用户关注点在CPU的那点利用率上。容器管理工具是必须的,他们可以作为一个守护进程运行在系统中,其中的诀窍把它公开、开源了。

据谷歌产品经理Martin Buhr说,谷歌更换Kubernetes的动机来自于一些官面的原因和一些自身的利益。谷歌希望开源的Kubernetes可以极大地扩展开发人员的生产力,从而使这个世界更加美好。更自私的讲,“随着时间的推移,我们将对谷歌云平台容器做全面的支持,将在市场上创造一个基于容器的应用程序,他们其中很大一部分会与我们同在的。”

换句话说,让开发和运维团队可以很舒服地使 用Kubernetes,所以他们可以选择谷歌的云平台更方便的使用。这是基本没有其他工作的,如果谷歌开始对Kubernetes有直接的货币利益,那对开源社区来说是个毒丸。

简而言之,Kubernetes的成功源于谷歌在代码层次15年的深耕细作,也因为谷歌渴望社区继续发展,并期待花费下一个15年去发展Kubernetes。

原文链接:Why Kubernetes is winning the container war (翻译:ylzhang)

原文发布时间为:2016-10-16

本文作者:ylzhang

原文标题:为什么Kubernetes能赢得容器之战

时间: 2024-08-04 14:41:19

为什么Kubernetes能赢得容器之战的相关文章

115浏览器正式版即将发布 国内浏览器之战谁主沉浮

中介交易 SEO诊断 淘宝客 云主机 技术大厅 当前,国内浏览器要数雨林木风的115浏览器最引人注目了,从115浏览器万元征集logo设计方案到115浏览器发布公测版,每次都引起站长轰动,不知115浏览器在国内浏览器市场日后能不能分一杯羹呢?115浏览器还有待市场锤炼.那国内主流浏览器有哪些呢?我们一起分享: 一.IE浏览器 IE 是微软的新版本Windows操作系统的一个组成部分.在旧版的操作系统上,它是独立.免费的.从Windows 95 OSR2开始,它被捆绑作为所有新版本的Windows

Puppet踏上容器之旅,全面支持Kubernetes

一年的时间足以沧海桑田,物是人非了,即使对企业也同样如此. 今年二月,Puppet Labs公司CEO Luke Kanies曾经在接受采访时表示,他认为Docker在企业环境下的快速普及基本上只是一种幻觉."没有哪种技术能够在企业当中拥有如此迅猛的传播速度.我根本不在乎它到底有多出色,"Kanies指出."大家不可能突然之间就把成百上千万种生产环境下的工作负载迁移到采用完全不同于以往的软件包.运行时以及其它组件的虚拟化层当中." 而就在不到一年之后,Puppet

决胜“云-端”:搜狗赢得入口之战?

云计算.云服务.云XX,一时之间,云成为了IT人士口中最时髦的话题,而人云亦云之时,当所有人被搞得云里雾里之时,云到底是什么,反而迷茫了. 易观国际前不久推出的<"云-端"模式--中国互联网增长新趋势报告>给出了一个答案:"互联网云服务时代的到来就目前而言仍然是一个假命题,中国互联网用户的上网条件,如网速慢.不稳定等仍然是用户体验云端服务的巨大障碍,未来几年客户端的计算能力与存储资源仍将无法迁移至云端." 入口是互联网的永恒之战 愚以为,之所以无法真正让

自己动手写Web容器之TomJetty(一) 服务内功经脉

Jetty 是一个开源的servlet容器,它为基于Java的web内容,例如JSP和servlet提供运行环境.Jetty是使用Java语言编写的,它的API以一组JAR包的形式发布.开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行(stand-alone)的Java应用提供网络和web连接.Tomcat 是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选. Jetty和To

自己动手写Web容器之TomJetty(六) 动态页面引入

在上一节,我们已经完成了TomJetty服务器处理静态页面请求的功能.但是只能处理静态页面请求的服务器并不能满足我们的要求,所以本节我们将为TomJetty服务器完成动态页面请求的处理工作. 所谓动态页面请求,无非就是客户端发送一个请求的url地址或者将一些请求参数提交给某一个url地址,服务器端首先接收到这个url地址并检索其在服务端程序中对应的某个处理类(Servlet),然后在该处理类中执行业务逻辑后产生结果,最终转发给相应的页面在客户端浏览器中显示结果. 一.动态页面请求处理 对于Jav

自己动手写Web容器之TomJetty(五) 包装请求参数

前面我们实现了TomJetty响应无参请求静态页面的功能,但真实情况下,几乎所有请求都得携带参数.不能处理用户参数请求的Web服务器就好比温室里的花朵,始终上不了台面.所以本节我们将为TomJetty加入响应用户参数的功能.此外,前面我们使用的提交请求的方式都是GET方式,但在实际情况下,POST方式使用的更广泛,所以我们也将给TomJetty增加响应POST请求的能力. 一.扩展RequestHeader类 1.在RequestHeader类中新增parameter属性,用于标示请求头中客户请

自己动手写Web容器之TomJetty(四) 静态页面起步

上一节我们实现了将HTTP请求头的内容解析后打印到控制台上,让HTTP请求头的各个组成部分完全暴露在在我们面前.这个功能在IE浏览器的一款叫作HttpWatch的插件中有类似的体现,相信很多读者都用过它,利用HttpWatch查看网页请求和响应的日志信息功能来调试程序.前面讲到我们把HTTP请求头封装在RequestHeader类中,这个类有一个url属性,本节我们将利用它来定位服务器端的静态页面. 一.服务端静态页面 作为一个Web服务器,响应客户端发送的请求是首要任务,怎样设计它才能快速地响

自己动手写Web容器之TomJetty(三) 掀起请求盖头来

前面我们对于实现TomJetty做了一些知识铺垫和复习,息知了HTTP请求的头部的组成元素.目前的TomJetty服务器已经能够成功启动,可是请求一旦过来却又看不懂^_^.所以本文就来解析HTTP请求头,剖析它的各部分.让TomJetty服务器能够明白它的意图. 一.HTTP请求头解析 1.编写一个RequestHeader类,用户封装请求头对象. package cn.lynn.tomjetty; import java.util.HashMap; /** * 封装请求头 * @author

自己动手写Web容器之TomJetty(二) 开启服务器

上一节我们对于实现TomJetty服务器做了一些与Web有关的知识铺垫和回顾.那么从本节正式开始实现TomJetty服务器的"山寨"之旅.要想实现一个服务器,第一步要把服务器建立起来,并且能够正常运行,才能等待来自客户端的请求.考虑到这一点,我们本节就来处理TomJetty服务器的创建和启动工作. 一.服务器建立 1.新建一个名为TomJetty的Java工程. 2.在工程根目录下新建一个tomjetty.config文件,用于提供服务器配置参数. tomjetty.port=9527