首页>软件资讯>行业资讯

行业资讯

redhat红帽OpenShift十周年:从PaaS到Kubernetes,再到云服务

发布时间:2022-11-30 10:48:27人气:356

redhat红帽OpenShift十周年:从PaaS到Kubernetes,再到云服务.png

十年前的这一周,在首届AWS re:Invent大会上,红帽的技术组合进行了一次超有信心的飞跃。在旗舰产品红帽企业Linux和JBoss中间件解决方案的成功基础上,推出了红帽OpenShift Enterprise 1.0,这是红帽专为企业开发人员提供的完全开源、混合平台即服务(PaaS)产品。 

现在,十年过去了。开源是所有技术创新的关键驱动力,无论是在数据中心还是在公有云中。Kubernetes是容器和云原生平台事实上的标准,边缘计算在企业IT中的存在感也越来越强。红帽OpenShift也已经改变了…


OpenShift的发展是一个持续向前的旅程。我们继续扩展到新的平台和用例,添加新的功能,增强现有功能,并开辟新的领域,以满足新兴的IT需求。说了这么多,为了让我们知道下一步要去哪里,我们需要了解来时的路。 


OpenShift的起源


虽然红帽OpenShift 1.0在2012年11月就开始普及,但它的实际概念要早得多,最初的开发始于2010年初,随后红帽在2010年晚些时候收购Makara,并在2011红帽全球峰会上发表了Paul Cormier的主题演讲,进行了介绍。 


开发人员纷纷涌向Heroku等新的公有云PaaS服务,这些服务支持自助应用部署并提高灵活性。CIO们也希望为自己组织中的开发人员推行更快的速度和敏捷性,他们认为PaaS的价值是能让企业应用开发人员工具和环境实现标准化,并创建一个通用的应用基础,无论应用的目的或代码基础是什么。他们喜欢PaaS的概念,但他们将企业应用转移到公有云的能力有限。


与红帽今天的整个混合云投资组合一样,OpenShift Enterprise 1.0使客户能够在混合云的任何环境中运行,包括他们的数据中心或任何公有云。OpenShift建立在红帽企业Linux (RHEL)的基础上,可以部署在RHEL认证可以运行,并使用基于RHEL的Linux容器部署应用的任何地方,这远远早于Docker的出现。 


在这个平台之上,开发人员可以选择应用语言和框架来部署他们的应用,从使用JBoss企业应用平台6或Tomcat的企业Java,到Ruby、Python、Node.js等。OpenShift在当时是独一无二的,它提供了一个完全开源的PaaS平台,提供了一系列多语言开发工具和功能,建立在RHEL的稳定性和增强的安全性上。 


俗话说,没有什么是一成不变的。 

Gears、cartridges和…Kubernetes


OpenShift的下一个次要版本,以及OpenShift Enterprise 2的主要版本,增加了OpenShift Origin上游社区开发的一系列特性,从改进的开发人员能力和更大的管理控制,到与OpenStack和其他基础设施平台更紧密的集成。OpenShift使用gears来运行您的应用,这些应用本质上是OpenShift的Linux容器的前身,正如我们今天所知道和喜欢的那样。 


Gears使用RHEL中的底层技术,如Linux内核名称空间、cGroups和SELinux,以提供一个高度可伸缩的、具有增强的安全态势的容器化应用平台。OpenShift还添加了“cartridges”,为平台带来新的应用运行时;本质上是由红帽合作伙伴打包在容器中运行的第三方应用,并验证了在OpenShift上工作的有效性。 


虽然这与目前OpenShift的能力相差很远,但它展示了使用容器部署应用可以获得的效率和灵活性,而不必发布虚拟机来构建和部署应用,还可以跨开发人员团队管理这些虚拟机的生命周期。这也表明了我们的合作伙伴生态系统对平台的成功是多么重要(一直、永远那么重要)。 


随着Docker容器的出现,以及不久之后Kubernetes的出现,一切都发生了变化。2013年Docker开源项目的启动成为了科技行业的一个分水岭。虽然Linux容器技术的根源可以追溯到Unix,并已经在OpenShift、Cloud Foundry甚至Heroku等解决方案中使用,但Docker使容器更简单,更易于开发人员访问,并使打包新应用在容器中运行变得更容易。 


红帽是最早加入Docker社区并为该项目做出贡献的公司之一。RHEL随后成为第一个宣布支持Docker容器的商业Linux操作系统。红帽后来与社区合作,推动了容器运行时和封装格式的开放容器倡议(Open Container Initiative, OCI)标准,该标准目前是所有容器化应用的行业标准。 


容器及其之前的设备,只不过是打包和运行单个应用服务的独特方式。然而,大多数应用需要多个微服务被编排和链接在一起,以形成一个更大、更复杂的应用。这就是Kubernetes作为大规模编排和管理容器的标准进入的地方。红帽很快意识到该项目的重要性,加入谷歌以启动Kubernetes社区,并通过OpenShift 3,让Kubernetes成为OpenShift平台的基础引擎。

用Operators操作不可变平台


OpenShift的Kubernetes骨干现在已经确定,但Kubernetes,嗯,很复杂。在OpenShift 3的早期,我们努力解决编排的复杂性,但应用和平台维护在规模上仍然是一个问题。2018年初,红帽收购了CoreOS,并与该公司一起推出了Tectonic平台,该平台集成了CoreOS容器Linux操作系统和Kubernetes operators的概念。 


Kubernetes operators建立在自定义资源定义(CRD)的基础上,为维护和更新云原生应用提供了可重复的模式或框架,基本上将在平台上运行的所有应用视为Kubernetes原生服务。同时,RHEL与CoreOS容器Linux的集成催生了RHEL CoreOS,并使该操作系统成为OpenShift Kubernetes平台的集成组件。RHEL CoreOS和运营商框架使部署OpenShift平台,和跨开放混合云向平台提供更复杂的服务变得更容易,在2019红帽全球峰会上发布了红帽OpenShift 4。 


今天,OpenShift 4是业界领先的企业Kubernetes平台,其重点是全面提供红帽OpenShift平台Plus,其中还包括红帽Kubernetes高级集群安全防护和红帽Kubernetes高级集群管理。OpenShift强调解决复杂性,并为服务维护创建可重复的模式,现在可以进一步聚焦在开发人员如何构建、部署和更新下一代应用。 

云服务……以及其他服务


早在OpenShift 1.0在2012AWS:Reinvent大会上发布之前,红帽就把OpenShift部署为公有云服务测试版,直接为开发人员提供反馈,并了解大规模运行托管PaaS云服务需要什么帮助。作为开放混合云的基础,OpenShift需要在客户要求的任何地方以任何方式运行,无论这是托管的还是自己管理的。在OpenShift Enterprise 1.0产品推出后不久,红帽开始推出完全托管的OpenShift云服务,首先是OpenShift Online,然后是OpenShift Dedicated。后来与AWS和微软Azure在联合管理的OpenShift云服务方面扩大合作就顺理成章了。 


今天,AWS上的红帽OpenShift云服务 (ROSA)、Azure Red Hat OpenShift和IBM Cloud上的红帽OpenShift,强调了OpenShift的当前迭代如何使自己适合管理服务模型。IT组织可以从强大和创新的混合云平台中获得好处,该平台可以在自己的数据中心和多个公有云之间,使用相同的技能和工具轻松转换,而开销和维护成本不高。企业IT的未来将不仅仅是在公有云或数据中心,它将是这些环境的混合,OpenShift的设计是为了满足这两种极端的需求。 


但我们并没有止步于此。随着边缘计算对几乎每个行业的企业都越来越重要,我们为OpenShift设计了部署模型,以满足这些需求。这包括使用单节点OpenShift的小型集群和单节点服务器部署,为OpenShift配置的硬件或新引入的(构建在MicroShift项目上的)红帽Device Edge提供零接触供应,该项目将Kubernetes从服务器带到边缘设备。OpenShift正在再次重塑自己,以应对下一波计算浪潮。 


这些只是平台的基本元素——OpenShift上开发人员的能力也在进化,以满足各种需求。可以看看看OpenShift Serverless、Service Mesh、pipeline或GitOps等例子,看看我们是如何满足新一代云原生应用需求的。 


那么接下来呢?如果看看OpenShift的历史,我们在哪里,我们是如何开始的,我们是如何改变的,我认为可以这样回答:无论计算领域的下一个趋势是什么,无论企业对混合云的需求如何变化,红帽OpenShift都将在其核心中存在。 



上一条:数据治理:元数据及元数据管理策略、方法和技术

下一条:倒计时1天,2022红帽论坛来咯~