随着移动互联网生态的兴起，传统银行面临跨界竞争，在电子商务支付、消费金融、商业融资的新的业务场景下面临严峻的挑战，数字化转型的需求日益迫切。在这场技术转型的浪潮下，各大银行积极推进科技改革，拥抱云计算，以适应市场不断的变化。随着容器技术的成熟，一个以Kubernetes容器编排引擎为核心的生态圈已经形成，互联网、金融、汽车等各企业都积极投入容器技术的应用中。容器云平台的建设已经被认为是云计算落地的一种快捷的方式。
说到容器云平台，就不得不提当前容器调度与编排的事实标准——Kubernetes。Kubernetes通过定义基础资源（容器、存储、网络）的协议接口，为底层基础设施提供了统一的管理方式。研发人员通过声明的方式定义资源编排文件，Kubernetes便通过自身组件自动完成资源的申请与分配，快速实现应用的部署。Kubernetes为容器的管理调度，应用的编排提供了便利，它无所不能，但是在建设企业级容器平台时，我们需要在以Kubernetes为核心的前提下，整合其他组件，例如网络插件、应用访问入口、存储实现、监控、日志、镜像仓库等。如图一所示。OpenShift正是基于Kubernetes实现的一个企业开源容器平台。
OpenShift发展历史
OpenShift是由RedHat推出的企业级Kubernetes平台，它是从OKD项目派生的下游容器编排技术。2019 年 9 月 IHS Markit Technology 统计了商业容器软件市场收入的排名，并发布了相关的调查报告。报告中显示红帽份额为 44%，排在第1位，超过了排名第2 - 第5公司的总和。从该报告的结果可以看出，在全球容器市场中，RedHat占有着领先的优势，而RedHat企业级容器产品便是OpenShift。
目前OpenShift最新版本为4.5，生产上使用最多的是3.11版本，也是3系列的最后一个版本。大家都知道OpenShift是基于Kubernetes实现的，但很多人并不清楚OpenShift其实早于Kubernetes诞生。整个OpenShift的发展过程中经历了两次重大的变革，如图二所示。
OpenShift发布于2011年，当时Docker还未出现，容器技术并没有像现在这么普及，也没有形成标准，而是一些大厂专用的技术，各家在容器运行时与容器编排引擎都各成一套，RedHat也不例外。OpenShift在v1与v2版本中一直使用的是RedHat自己开发的容器运行时与容器编排引擎。随着2013年Docker的问世，RedHat立刻意识到了该技术将带来的革命，随即与Docker展开合作，确定了以Docker作为下一代OpenShift容器运行时。在2014年Kubernetes的发布，RedHat经过调研，便很快与Google展开合作，确认了以Kubernetes作为下一代OpenShift的编排引擎。后来的事实证明RedHat做的这两个选择都非常明智。
2015年OpenShift迎来了第一个重大的变革，OpenShift v3发布。RedHat弃用了原先自己的“Gear”和“Cartridge”技术，以Docker、Kubernetes为核心进行全新重构，并且站在开发者的角度，对产品体验进行了全面的升级与优化。OpenShift 3很快得到了开发者的认可，取得了巨大的成功，直到今天使用最多的版本仍然是v3版本。
OpenShift本可以沿着v3的路线不断升级完善，就能够保持自己在容器PaaS领域的优势，然而它的变革并未停止。2018年红帽收购了容器领域的另一巨头CoreOS，容器领域的两只领头羊合二为一，他们将各自积累多年的容器技术进行全面融合，通过Operator实现应用全生命周期的自动化管理，对OpenShift 3版本进行全面的改造，推出了功能更加丰富，更加自动化的4版本，这里不得不佩服红帽的魄力。
OpenShift对Kubernetes的增强
OpenShift与Kubernetes的关系类似于Linux与Linux发行版（Rhel、Ubuntu等）的关系。OpenShift以Kubernetes为核心，实现相关的资源协议接口，对其功能进行增强，同时整合其它组件，使其成为企业级容器平台。
OpenShift提供稳定的容器、网络、存储等资源协议接口的实现。
- 以Docker作为默认的容器运行时，对接Kubernetes的容器运行时接口（CRI），当然OpenShift也支持其它的容器运行时，比如CRI-O。
- OpenShift默认采用OVS作为容器平台的网络插件，对接Kubernetes的容器网络接口（CNI），实现容器跨主机的网络通信及管理，同时OpenShift也支持其它的网络插件，比如Calico。
- 存储类型方面，除了Kubernetes默认支持的RBD、NFS、EBS、GlusterFS等，OpenShift支持更多的存储类型，如Local、iSCSI等。
OpenShift对原生Kubernetes的安全性及功能进行了增强。 - OpenShift最早实现了集群的多租户管理，比如RBAC、Qouta、Namespace等，这些能力在Kubernetes的后期版本中才集成。
- 为了提高安全性，OpenShift开发了安全上下文约束（SCC），控制容器运行时默认使用最小权限。
- 为了方便研发人员的持续构建与部署，OpenShift开发了DeploymentConfig及BuildConfig资源，它们在Kubernetes的应用编排资源的基础上添加了更多的控制能力，比如自动触发、部署策略等。
- OpenShift实现了Route资源对象，为集群提供了统一的网络入口，方便集群中的应用对外提供服务。受到Route的启发，Kubernetes目前也开发类似功能的实现Ingress。
- OpenShift开发了集群内部镜像仓库，并且提供了与应用资源协调调用的能力。
OpenShift整合了更多的组件，增强了集群的稳定性。 - 基于Prometheus、Grafana、AlertManager为集群提供了整体监控与告警的方案，包括集群核心组件的可用性，容器资源使用率等，同时也提供了自定义监控项的扩展能力。
- 基于EFK组件，为集群组件及应用提供了整体的日志统一管理方案。
另外还需要提的是，OpenShift为开发者和集群管理者提供了一个非常容易使用的控制台，通过控制台可以方便完成绝大部分的使用与管理。
从上面可以看出，OpenShift的能力对Kubernetes较全面的增强，同时两者又是相辅相成，OpenShift基于Kubernetes实现，也同样反馈与驱动Kubernetes前进。
OpenShift的不足
OpenShift提供了一个开箱即用的单容器高可用容器PaaS平台，它可以满足绝大部分企业容器应用部署的需求，为企业能够快速构建自己的云计算服务。但是大型企业容器平台建设需要考虑的情况往往会更复杂。
- 应用的部署体验够用了吗？OpenShift提供了单平台web控制台，它的可定制化能力较弱，很难对其进行扩展。
- 多中心、多集群管理有没有？OpenShift更多的是对单集群的管理，缺乏多集群管理的能力。
- 生产级别的PaaS服务有没有？OpenShift提供了应用商店，更多的并没有达到生产级别的要求，只能在开发测试环境试用。
- 与企业流程的深度融合有没有？如果需要与企业自身系统进行深度融合，需要对OpenShift控制台进行深度化定制，往往我们还是需要独立开发门户网站。
- 监控集群及应用是否可以自定制？OpenShift集群提供了整体监控与告警的产品化方案，其监控展示配置是固化的，无法自定义自己的监控展示页面。
- 日志方案是否足够了？在日志方案上，OpenShift能够满足一般吞吐量的日志收集与管理，随着集群规模的壮大，应用日志并发数增多，OpenShift日志系统会受到性能瓶颈。
- 集群的网络是否有局限性？OpenShift默认采用ovs作为容器平台的网络插件，它是一种overlay网络，容器间访问需要通过封包解包，这在一定程度上降低了网络性能，同时对于集群内外服务的网络控制也增加了一定的难度。
另外各企业有自己的审批流程、开发流程、运维规范、更高的高可用要求、更高的性能要求、更细化的安全要求、自主可控等。而OpenShift产品化程度过高，降低了其自身的灵活性，企业对其定制能力被削弱。所以各大企业即使引入了OpenShift平台，仍然需要在它的基础上建设自己的容器平台门户，并且相关的技术方案也需要独立设计。
OpenShift 4——全新一代OpenShift
2019年5月，在完成收购CoreOS的15个月后，RedHat正式发布了OpenShift 4，将其定位为面向混合云的通用操作系统，如图三所示。它虽然依然以Kubernetes为核心，但是整个平台已经脱胎换骨，从功能，架构，到实现都有非常大的改变。其中最大的变化是在底层的操作系统及应用服务的管理方式上。
- 采用更轻量、更安全、更紧凑的CoreOS操作系统，容器运行时也使用更轻量的CRI-O代替了Docker。CoreOS是一个基于Linux内核的轻量级操作系统，专注于自动化、轻松部署、安全、可靠及可扩缩性，它可以通过配置文件来定义底层操作系统，实现了操作系统的标准化。
- 全面拥抱Operator，实现应用服务自动部署、自动运维、扩展及故障转移，极大程序简化了应用的管理，同时保证了不同的集群下应用都是完全相同的，无论是内部环境还是公有环境，实现了应用管理的标准化。OpenShift集群的核心组件，运维组件，DevOps工具链等都实现了Operator化。
OpenShift 4自身的内功修炼也不止这些：Serverless的支持、服务网格技术的整合、多网络平面的支持、更多持续集成与持续交付功能的拓展等，为应用的全生命周期打造一个完善的生态系统。
除了自身的功能外，OpenShift 4与各种云平台的集成方面下足了功夫，支持了AWS、Azure Cloud、VMware vsphere、IBM Cloud等，甚至将会支持与Aliyun的集成。这也解释了为什么它的定位是面向混合云的通用操作系统。
虽然当前OpenShift 4还是一个较新的版本，稳定性还需要更多的生产实践进行验证。但是相信在不久的将来OpenShift 4会接过V3的大旗，成为生产上使用最为广泛的容器平台。
总结
OpenShift在过去几年的不断创新与探索，敢于自我革命，成就了现在企业级容器平台的江湖地位。虽然OpenShift的产品化降低了它的灵活性，但是它对原生Kubernetes在安全性、稳定性等多个方面进行了增强。在容器平台建设过程中，我们需要结合自身的情况，综合考虑，进行多维度的评估。
