redhat红帽OpenShift十周年：从PaaS到Kubernetes，再到云服务

十年前的这一周，在首届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红帽论坛来咯~