标签：信息技术 接口 链接 环境 管道 性能 iar 停止 BYD
近十年来，信息技术领域在经历一场技术大变革，这场变革正将我们由传统IT架构及其所支撑的臃肿应用系统时代，迁移至云原生架构及其所支撑的敏捷应用系统时代。在这场变革中，新技术的出现、更新和淘汰之迅速，以及新技术的架构集成度、复杂度之高，都是前所未有的。从虚拟化到云计算，从虚拟机到容器，从微服务到无服务器计算，技术的持续演进和推陈出新在不断重构企业的组织文化和商业逻辑的同时，也在推动企业朝着数字化、智能化时代迈进。
但是，频繁更新的技术及其复杂程度给IT从业者，尤其是企业开发人员，也带来了空前的挑战，如何在保证业务高速发展的前提下，仍然保持持续创新的能力和对众多新技术的学习研究、掌握应用的能力，是每位IT从业者都在思考和权衡的问题。此外，如何从复杂多变的软件技术体系中把握住未来的技术趋势，并将之提前布局应用到业务创新领域，以便掌握竞争先机，这是每个企业的技术负责人必须考虑的问题。平台技术和开源社区为我们提供了解决问题的途径，而这也正是我们选择OpenShift开源PaaS平台的原因之一。
OpenShift是由RedHat推出的企业级Kubernetes平台，其主要目标是构建以OCI（Open Container Initiative）容器封装和Kubernetes容器集群管理为核心，对应用生命周期进行管理并实现DevOps工具链等完整功能的开源容器PaaS平台。OpenShift对应用的持续开发、多租户部署和安全管控等进行了优化，并在Kubernetes的基础上增加了以开发人员和操作管理为中心的工具集，以便实现应用程序的快速开发、轻松部署、简单扩展和全生命周期的维护。OpenShift在上游开源社区的版本名称是OKD（最初叫Origin），OKD版本与Kubernetes发行版本相对应，如OKD 1.10对应Kubernetes 1.10。
需要指出的是，OpenShift并非在诞生之初就是以Docker和Kubernetes为核心的PaaS平台。OpenShift诞生于2011年，主要依赖于Linux容器来部署和运行用户应用程序，在OpenShift的v1和v2版本中，使用的一直是RedHat自己特定于专有平台的容器运行时和容器编排引擎。早期的OpenShift使用一种称为“Gear”的专有容器技术，并通过一种称为“Cartridge”的技术来制作容器模板。随着2013年Docker容器技术的问世和流行，RedHat开始与Docker公司合作，并在2014年8月宣布将在OpenShift v3版本中采用Docker容器。随着Docker容器技术的普及，以Mesos、Docker Swarm和Kubernetes为主的大规模容器集群编排调度引擎开始出现，RedHat也逐渐意识到容器编排引擎在OpenShift中的重要性，并在进行了一系列调研之后选择了Kubernetes作为OpenShift v3版本的调度引擎。
2015年，对于RedHat来说具有划时代意义的OpenShift v3版本诞生，由OpenShift v1和v2版本中基于“Gear”和“Cartridge”的技术，完全重构为v3版本中基于Docker和Kubernetes的技术，OpenShift v3开始以标准和开放的姿态领跑PaaS。在Kubernetes之上，OpenShift v3又引入了强大的用户界面，通过源代码到镜像（Source-to-Image，S2I）和管道（Pipeline）技术快速创建和部署应用程序，OpenShift v3版本迅速获得了大量开发者，并成为PaaS当仁不让的王者。然而，OpenShift的发展并未停止，在2018年完成对CoreOS的收购，对Service Mesh（Istio）和Serverless（Knative）等技术的集成，并使用Kubernetes Operator来实现应用程序管理的自动化之后，RedHat在2019年发布了OpenShift v4版本（如图1-11所示）。OpenShift v4版本的问世，意味着全栈融合PaaS时代的到来，向上通过Operator实现应用全生命周期的自动化管理，向下通过CoreOS实现基础设施的自动化管理。也许未来，裸机以上都将在OpenShift的统管之下！
图1-11 OpenShift发展简史
在云原生架构时代，我们在谈数字化转型的时候，实质上就是在谈组织架构、应用流程和基础架构设施的转型。近十年来，我们的开发流程从瀑布到敏捷再到DevOps，应用架构从单体到多层再到微服务架构，软件交付与封装经历了物理机、虚拟机再到容器，应用运行的基础设施也从传统数据中心到主机托管再到云计算（如图1-12所示），技术的变革在多个维度同时进行，云计算、DevOps、容器、微服务架构等技术的成熟与普及，事实上也预示着云原生时代的到来。
在云原生时代，企业应该如何构建自己的云原生平台，以支撑其数字化转型过程中的应用云化迁移呢？企业若要从下至上地构建自己专属的云原生平台，其过程将是极其复杂的。我们以完全采用开源技术栈构建云原生平台为例，首先需要通过Linux、OpenStack、Ceph等开源系统和集群软件构建IaaS层，然后再基于Kubernetes和Docker技术来构建PaaS层。事实上难度是在PaaS层的构建上，因为在PaaS层，基于Kubernetes的功能，我们还需要自己实现对多语言运行环境、各类中间件、数据库等服务编目的支持，实现应用的自动构建与部署、基于CI/CD和DevOps的应用全生命周期管理，实现镜像仓库、日志、监控、服务追踪、安全和多租户等集群管理功能，实现基于Web的集群管理和自助服务的极好用户体验，实现对诸如Istio等微服务架构和Knative等Serverless应用架构的支持。
而这一切的实现，对于很多企业而言，将会是个极大的挑战。因为这需要集成来自众多开源社区的软件，而每一个开源软件的应用都意味着极大的学习成本、时间成本以及不确定性风险。然而，驱动开源社区、集成开源技术正是OpenShift的价值所在。如图1-13所示，RedHat以OpenShift为中心，以其多年在开源社区的耕耘为基础，以开源方式集成了用户所能想到和用到的各种开源软件。从这个层面上来讲，我们可以认为OpenShift本身就是个集成创新引擎。
图1-12 信息技术的变革
图1-13 OpenShift生态圈集成创新引擎
因此，借助OpenShift构建企业级云原生平台将会事半功倍。因为在最新的OpenShift v4版本中，借助不可变容器操作系统CoreOS，裸机以上部分，OpenShift已完全实现自动化接管。当然，OpenShift也支持在公有云、私有云和混合云上部署实现，目前已支持在AWS、Azure、GCP、OpenStack和vSphere等公有云和私有云平台上的自动部署。因此，借助企业级开源PaaS平台OpenShift，企业云原生平台的构建将可一步到位。如图1-14所示，OpenShift已基本集成并实现了云原生平台所需的全部软件和功能。
图1-14 OpenShift构建企业云原生平台
Kubernetes是主流的容器编排引擎，也是CNCF孵化出的最成功的项目。在一定程度上，可以认为OpenShift的成功离不开Kubernetes社区的支持，或者说正是Kubernetes的成功赋予了OpenShift极强的生命力，Kubernetes已成为OpenShift不可分割的一部分。前文提到，OpenShift v3以后的版本都是基于CRI容器技术和Kubernetes重构的版本，那么OpenShift与Kubernetes之间究竟有什么关系？企业为什么不直接使用Kubernetes而要选择使用OpenShift呢？或者说选择OpenShift的企业用户将会获得什么好处呢？本节中我们将就这几个问题进行重点讨论，以消除很多用户对于OpenShift和Kubernetes的困惑。
首先，我们要清楚OpenShift更偏向于一个产品，而Kubernetes是一个开源项目。这就意味着OpenShift在安全性、易用性、多租户和用户体验等方面必然优于Kubernetes，这是一个产品区别于一个开源项目最明显的地方（OpenShift企业级功能特性如图1-15所示）。举一个比较直观的例子，OpenShift 的用户接口界面体验要远优于Kubernetes原生界面。OpenShift的商业产品叫作OpenShift容器平台（OpenShift Container Platform，OCP），通过订阅RedHat的OCP服务，企业用户可以获得来自RedHat的专业服务和支持，而如果使用Kubernetes，就只能获取社区的技术支持，这是很多企业用户在进行技术选型时的一个重要考虑因素。另外，OpenShift也提供了开源版本OKD，OKD具有与商业版本类似的功能，只是RedHat不提供技术支持和服务，用户需要自己对OKD有较为深入的理解。（帮助用户理解OKD正是我们写作本书的目的所在。）
图1-15 OpenShift企业级功能特性
其次，OpenShift发行的每个版本与Kubernetes基本上是对应的，Kubernetes每年大概发行4个版本，与之对应的OpenShift版本通常会滞后1到3个月发行，在这段时间内RedHat会对最新的Kubernetes版本进行测试，并在缺陷（Bug）和性能问题修复后，集成各种经过验证的中间件服务和功能软件，如用于CI/CD管道的Jenkins、用于监控的Prometheus、用于可视化的Grafana、服务网格Istio、无服务器计算Knative等。所以，OpenShift在稳定性和软件集成度上要远优于直接使用Kubernetes。
最后，虽然OpenShift是基于Kubernetes实现的，但是OpenShift也会反馈并驱动Kubernetes的发展。OpenShift的产品属性决定了其目标用户是企业而非个人，因此OpenShift中很多企业级的需求和功能最终也会反馈到Kubernetes社区中，如Kubernetes中的Ingress、Deployment的部分功能实现就分别来自OpenShift中的Route和Deployment Configurations。另外，Kubernetes中基于角色的访问控制（RBAC）功能也源自OpenShift。所以说，就企业用户而言，OpenShift有更多适合企业使用的功能，而Kubernetes通常需要在企业用户反馈后才能开发出这些功能。OpenShift的产品属性决定了其会主动满足企业用户需求，而Kubernetes的项目属性决定了其是被动响应企业用户需求。
总体而言，从功能上来看，Kubernetes具备的功能特性OpenShift一定具备，但是OpenShift具有的某些企业级功能特性Kubernetes却不一定拥有。从集成度上来看，OpenShift是基于Kubernetes的高度集成产品，如果将OpenShift看成操作系统，那么Kubernetes就是这个系统的内核。系统极客只需安装内核，然后自己编译安装需要的依赖软件，也能运行应用程序，但是对于普通用户而言，一个仅有内核系统的使用成本和代价都是极高的。简单来说，Openshift是一个用于构建、部署和智能化管理生产环境中Kubernetes应用程序的完整平台，通过OpenShift这个完整的PaaS平台，我们即可一步到位地迈向云原生时代！
购买链接：https://item.jd.com/12640959.html
感谢您的阅读，欢迎关注我的微信公众号：
新书《OpenShift云原生架构：原理与实践》第一章第三节：企业级PaaS平台OpenShift
标签：信息技术 接口 链接 环境 管道 性能 iar 停止 BYD
原文地址：https://www.cnblogs.com/sammyliu/p/12862981.html
