科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道产业观察解疑:为何红帽OpenShift选用Kubernetes?

解疑:为何红帽OpenShift选用Kubernetes?

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

为什么红帽决定在Kubernetes基础上对OpenShift进行标准化,而不是采用其他容器编排解决方案呢?这可能是很多人心中的疑惑。今天,红帽产品管理高级总监Joe Fernandes为您介绍背后的缘由。

作者:Joe Fernandes 来源:至顶网软件频道2017-07-04 16:04:58

关键字: kubernetes OpenShift 红帽

  • 评论
  • 分享微博
  • 分享邮件

至顶网软件频道消息:红帽公司的企业Kubernetes发行版,既可以用作商业软件解决方案(OpenShift容器平台,可以运行在OpenStack、VMware、AWS、GCP、Azure 以及任何支持RHEL 7的平台上),也可以用作公共云服务(OpenShift Dedicated和OpenShift Online)。

三年前的一个重要决定

OpenShift在2011年首次推出,一直依赖Linux容器来部署和运行用户应用。在OpenShift v1和v2中,如同许多依赖容器的PaaS解决方案一样,使用红帽自己的与特定平台相关的容器运行时和容器编排引擎。

解疑:为何红帽OpenShift选用Kubernetes?

在2013年年中,红帽做出了一项决定,支持docker开源项目,并帮助推动容器运行时和包装格式的行业标准。我们在红帽企业版Linux 7(以及Fedora和CentOS)中提供了完整的docker支持,这成为OpenShift 3的基础。

但是,红帽一直很清楚,OpenShift不仅仅需要一个容器运行时。真正的应用不是运行在单个容器中,而且实际的生产应用不是部署在单个主机上。能够在多个主机之间协调多个容器是OpenShift的一个关键要求。

在2013年下半年和2014年初,红帽调研了一些方案,包括docker社区中新出现的一些编排方面的工作,并对Mesos进行了彻底评估,我们甚至还尝试构建我们自己的OpenShift特定编排解决方案。我们甚至听到来自Twitterati的呼吁,建议红帽应该支持其他项目,而不是OpenShift。

最终,经过调研,我们选中了Kubernetes。现在回头来看,这有三个主要原因……

了不起的技术

关于Kubernetes,我们首先注意到并仍然非常喜欢的,是其针对容器编排和管理的强大基元(primitive)。这包括:

  • Kubernetes pod,它能够让开发人员将一个或多个容器部署为单个原子单元。

  • 能够访问某个固定地址和集成IP中的一组pod的服务,以及基于DNS的服务发现功能,可以将这些服务链接在一起。

  • 复制控制器能够确保所需数量的pod始终保持运行,而且有众多标签来识别pod和其他Kubernetes对象。

  • 强大的网络模型,用于管理跨多个主机的容器。

  • 能够协调存储器,从而让您在容器中运行无状态和有状态的服务。

  • 简化的编排模型,能够快速让多个应用投入运行,而无需复杂的双层调度器

  • 一套具有下述能力的架构:认识到开发人员和操作人员的需求是不同的,并将这两种需求统筹考虑,从而无需对这两项重要的功能做出妥协。

我们还喜欢的一点是,Kubernetes是采用Go语言编写的,而且是专为容器编排而设计的。我们在docker社区中或者在我们自己的开发工作中都没有看到类似的东西。

虽然Mesos在大数据方面已经拥有良好的记录,但它更多地关注集群管理,并依靠诸如Marathon或Aurora这样的插件来编排容器化的应用服务。这些插件的能力赶不上我们在Kubernetes中看到的能力,而且Mesos本身是一个更复杂的C++代码库,我们认为它更难以扩展和维护。

即使在今天,我们仍然看到,诸如Docker Swarm和Mesos这样的解决方案还在复制Kubernetes最先推出的许多容器编排基元。但是,Kubernetes社区并没有停滞不前;随着每个版本的发布,Kubernetes的创新一直在以惊人的速度继续前进。

了不起的合作伙伴

回顾我过去的电子邮件,我发现我们第一次与Google讨论容器的话题是在2014年3月初。

那次会议的参加者包括Craig McLuckie、Joe Beda、Brendan Burns、Martin Buhr、Ville Aikas以及Google公司Kubernetes项目的其他先驱。当然,当时我们不知道Kubernetes的存在。我们的目的只是讨论两家公司在Docker社区所做的工作,并探索可以一致行动的领域。

Google和红帽两家公司都是Linux和容器技术的长期贡献者。正是Google于2006年在Linux 控制小组(Cgroups)中的工作形成了Linux容器的基础,并使得像Docker这样的项目得以存在。红帽也对Linux的容器技术做出了广泛的贡献,而且与Google一起迅速成为docker项目的顶级贡献者。

在那次会议上,我们了解到,Google不仅支持Docker,还将其引入Google云平台,而且他们还在容器编排方面开展了一个新项目。这个项目,当时代号为“Seven of Nine”,后来展示给红帽工程部负责人以及其他人,他们都对其一见钟情!许多编排功能来自Google自己多年来运行诸如Borg等传统系统,以及大规模编排容器方面的经验。

从这一点上说,它是一个老生常谈的东西,但是在Google,任何东西都运行在容器中,而且当你每个星期都部署数十亿个容器时,你很快就会知道什么东西能奏效,什么东西不起作用。

“Seven of Nine”项目最终变成了Kubernetes,并在那年七月推出,一年后在2015年7月达到了 1.0 状态。我经常听说,评价一家公司时,你应该关注其员工,而不是关注其产品。在这方面,Google 云计算小组当仁不让,他们在容器以及大规模管理容器方面的知识和经验都是首屈一指的。

真正了不起的社区

人们在评估开源软件时常犯的错误是花费太多时间考察技术,而没有用足够的时间来评估它周围的社区。这是我担任红帽公司产品经理时学到的第一课。任何开源技术的当前状态只是时间长河中的一瞬间。而它周围的社区的状态才是决定其创新速度的东西,而且也决定着该技术将会如何随着时间的推移而发展。

在短短一年多的时间里,Kubernetes社区贡献者数量已经壮大到任何其他容器编排项目的4倍,并已成为Github上增长最快的开源项目之一。现在,在云原生计算基金会(CNCF) 的治理下,我们看到众多公司和个人贡献者正在开展卓越协作和创新。

从我们最早与Google讨论开始,我们就看到他们致力于建立一个完全开放的、基于精英管理的社区。他们邀请红帽加入该社区,并请求我们就如何塑造它提出建议。

当2014年7月Kubernetes最终作为开源项目发布时,红帽也加入了发布活动;目前红帽是仅次于Google的第二位贡献者。在Google的支持下,红帽一直致力于帮助Kubernetes扩大企业用户使用案例,而且正是通过OpenShift来实现这一目标。

Kubernetes社区的活力体现在项目的快速增长,以及每一个版本发布时所引入的大量新功能。现在我们看到,Kubernetes不断扩展,运行规模达到新层次,从而能够支持新的工作负载、推动新的集群联合、满足企业在安全性和可管理性方面的要求,同时提高了易用性。

喜欢就说出来,我本人以及整个红帽团队都非常高兴红帽为OpenShift选择了Kubernetes。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    相关文章
    最新文章