官网 https://www.redhat.com/en/technologies/cloud-computing/openshift
Red Hat OpenShift Container Platform (OpenShift)是一个容器应用程序平台,它为开发人员和IT组织提供了一个云应用程序平台(PaaS),用于在安全的、可伸缩的资源上部署新应用程序,而配置和管理开销最小。
OpenShift构建于Red Hat Enterprise Linux、Docker和Kubernetes之上,为当今的企业级应用程序提供了一个安全且可伸缩的多租户操作系统,同时还提供了集成的应用程序运行时和库。
OpenShift带来了健壮、灵活和可伸缩的特性。容器平台到客户数据中心,使组织能够实现满足安全性、隐私性、遵从性和治理需求的平台。不愿意管理自己的OpenShift集群的客户可以使用Red Hat提供的公共云平台OpenShift Online。
OpenShift提供了丰富的容器化管理功能,其核心功能包括以下内容:
OpenShift容器平台和OpenShift Online都是基于OpenShift Origin开源软件项目的,该项目本身使用了许多其他开源项目,如Docker和Kubernetes。
应用程序作为容器运行,容器是单个操作系统内的隔离分区。容器提供了许多与虚拟机相同的好处,比如安全性、存储和网络隔离,同时需要的硬件资源要少得多,启动和终止也更快。OpenShift使用容器有助于提高平台本身及其承载的应用程序的效率、灵活性和可移植性。
OpenShift的主要特性如下:
OpenShift 有两个版本:开源版本和企业版本。
总的来说,企业版本相对于开源版本提供了更加全面和强大的功能和支持,更适合于大规模的企业级应用场景。但是,开源版本更加灵活和自由,也更适合于小型和中型企业以及个人开发者。
OpenShift容器平台是一组构建在Red Hat Enterprise Linux、Docker和Kubernetes之上的模块化组件和服务。OpenShift增加了远程管理、多租户、增强的安全性、应用程序生命周期管理和面向开发人员的自服务接口。
OpenShift在Docker + Kubernetes基础设施之上添加了提供容器应用程序平台所需的更富丰的功能:
OpenShift不会向开发人员和系统管理员屏蔽Docker和Kubernetes的核心基础设施。相反,它将它们用于内部服务,并允许将Docker和Kubernetes资源导入OpenShift集群,同时原始Docker和资源可以从OpenShift集群导出,并导入到其他基于docker的基础设施中。
OpenShift添加到Docker + Kubernetes的主要价值是自动化开发工作流,因此应用程序的构建和部署在OpenShift集群中按照标准流程进行。开发者不需要知道底层Docker的细节。OpenShift接受应用程序,打包它,并将其作为容器启动。
OpenShift集群是一组节点服务器,它们运行容器,并由一组主服务器集中管理。服务器可以同时充当master和node,但是为了增加稳定性,这些角色通常是分开的。
OpenShift工作原理和交互视图:
OpenShift master运行Kubernetes master服务和Etcd守护进程;node运行Kubernetes kubelet和kube-proxy守护进程。虽然在描述中通常没有声明,但实际上master本身也是node。
Kubernetes的调度单元是pod,它是一组共享虚拟网络设备、内部IP地址、TCP/UDP端口和持久存储的容器。pod可以是任何东西,从完整的企业应用程序(包括作为不同容器的每一层)到单个容器中的单个微服务。例如,一个pod:一个容器在Apache下运行PHP,另一个容器运行MySQL。Kubernetes管理replicas来缩放pods。副本是一组共享相同定义的pod。
除了Kubernetes的资源(如pods和services)之外,OpenShift还管理projects和users。一个projects对Kubernetes资源进行分组,以便用户可以使用访问权限。还可以为projects分配配额,从而限制了已定义的pod、volumes、services和其他资源。
OpenShift中没有application的概念,OpenShift client提供了一个new-app命令。此命令在projects中创建资源,但它们都不是应用程序资源。这个命令是为标准开发人员工作流配置带有公共资源的proiect的快捷方式。
OpenShift使用lables(标签)对集群中的资源进行分类。默认情况下,OpenShift使用app标签将相关资源分组到应用程序中。
OpenShift允许开发人员使用标准源代码管理仓库(SCM)和集成开发环境(ide)来发布应用。
OpenShift中的source -to-lmage (S2I)流程从SCM仓库中提取代码,自动判断所需的runtime,基于runtime启动一个pod,在pod中编译应用。
当编译成功时,将在runtime image中添加层并形成新的image,推送进入OpenShift internal registry仓库,接着基于这个image将创建新的pod,运行应用程序。
S2I可被视为已经内置到OpenShift中的完整的CI/CD管道。
CI/CD有不同的形式,根据具体场景表现不同。例如,可以使用外部CI工具(如Jenkins)启动构建并运行测试,然后将新构建的映像标记为成功或失败,将其推送到QA或生产。
OpenShift资源定义,如image、container、pod、service、builder、template等,都存储在Etcd中,可以由OpenShift CLI, web控制台或REST API进行管理。
OpenShift的资源可通过JSON或YAML文件查看,并且在类似Git或版本控制的SCM中共享。OpenShift甚至可以直接从外部SCM检索这些资源定义。
大多数OpenShift操作不需要实时响应,OpenShift命令和APIs通常创建或修改存储在Etcd中的资源描述。Etcd然后通知OpenShift控制器,OpenShift控制器会就更改警告这些资源。
这些控制器采取行动,以便使得资源的最终态反应达到更改效果。例如,如果创建了一个新的pod资源,Kubernetes将在node上调度并启动该pod,使用pod资源确定要使用哪个映像、要公开哪个端口,等等。或者一个模板被更改,从而指定应该有更多的pod来处理负载,OpenShift会安排额外的pod(副本)来满足更新后的模板定义。
注意:虽然Docker和Kubernetes是OpenShift的底层,但是必须主要使用OpenShift CLi和OpenShift APls来管理应用程序和基础设施。OpenShift增加了额外的安全和自动化功能,当直接使用Docker或Kubernetes命令和APls时,这些功能必须手动配置,或者根本不可用。因此强烈建议不要使用docker或Kubernetes的命令直接管理应用。
Docker网络相对简单,Docker创建一个虚拟内核桥接器(docker0网卡),并将每个容器网络接口连接到它。
Docker本身没有提供允许一个主机上的pod连接到另一个主机上的pod的方法。Docker也没有提供向应用程序分配公共固定IP地址的方法,以便外部用户可以访问它。
但Kubernetes提供service和route资源来管理pods之间的网络,以及从外部到pods的路由流量。service在不同pods之间提供负载均衡用于接收网络请求,同时为service的所有客户机(通常是其他pods)提供一个内部IP地址。
container和pods不需要知道其他pods在哪里,它们只连接到service。route为service提供一个固定的惟一DNS名称,使其对OpenShift集群之外的客户端可见。
Kubernetes service和route资源需要外部(功能)插件支持。service需要软件定义的网络(SDN),它将在不同主机上的pod之间提供通信,route需要转发或重定向来自外部客户端的包到服务内部IP。
OpenShift提供了一个基于Open vSwitch的SDN,路由由分布式HAProxy farm提供。
pod可以在一个节点上停止,并随时在另一个节点上重新启动。同时pod的默认存储是临时存储,通过对于类似数据库需要永久保存数据的应用不适合。
Kubernetes为管理容器的外部持久存储提供了一个框架。Kubernetes提供了PersistentVolume资源,它可以在本地或网络中定义存储。pod资源可以使用PersistentVolumeClaim资源来访问对应的持久存储卷。
Kubernetes还指定了一个PersistentVolume资源是否可以在pod之间共享,或者每个pod是否需要具有独占访问权的自己PersistentVolume。当pod移动到另一个节点时,它将保持与相同的PersistentVolumeClaim和PersistentVolumne资源的关联。这意味着pod的持久存储数据跟随它,而不管它将在哪个节点上运行。
OpenShift向Kubernetes提供了多种VolumeProvider,如NFS、iSCSI、FC、Gluster或OpenStack Cinder。
OpenShift还通过StorageClass资源为应用程序提供动态存储。使用动态存储,可以选择不同类型的后端存储。后面存储根据应用程序的需要划分为不同的“tiers”。例如,可以定义一个名为“fast”的存储类和另一个名为“slow”的存储类,前者使用更高速的后端存储,后者提供普通的存储。当请求存储时,最终用户可以指定一个Persistentvolumeclaim,并使用一个注释指定他们所需的StorageClass。
OpenShift平台集群的高可用性(HA)有两个不同的方面:
默认情况下,OpenShift为master提供了完全支持的本机HA机制。
对于应用程序或“pods”,如果pod因任何原因丢失,Kubernetes将调度另一个副本,将其连接到服务层和持久存储。如果整个节点丢失,Kubernetes会为它所有的pod安排替换节点,最终所有的应用程序都会重新可用。pod中的应用程序负责它们自己的状态,因此它们需要自己维护应用程序状态(如HTTP会话复制或数据库复制)。
要在OpenShift中创建一个新的应用程序,除了应用程序源代码之外,还需要一个base image(S2I builder image)。如果源代码或image任何一个更新,就会生成一个新的image,并且基于此新image创建新的pod,同时替换旧的pod。
即当应用程序代码发生更改时,容器映像需要更新,但如果构建器映像发生更改,则部署的pod也需要更新。
Image Streams包括由tag标识的大量的image。应用程序是针对Image Streams构建的。Image Streams可用于在创建新image时自动执行操作。构建和部署可以监视Image Streams,以便在添加新image时接收通知,并分别执行构建或部署。
OpenShift默认情况下提供了几个Image Streams,包括许多流行的runtime和frameworks。
Image Streams tag是指向Image Streams中的image的别名。通常缩写为istag。它包含一个image历史记录,表示为tag曾经指向的所有images的堆栈。
每当使用特定的istag标记一个新的或现有的image时,它都会被放在历史堆栈的第一个位置(标记为latest)。之前tag再次指向旧的image。同时允许简单的回滚,使标签再次指向旧的image。
OpenShift 是一个基于 Kubernetes 的容器应用平台,它在 Kubernetes 的基础上添加了一些额外的功能和工具,以帮助用户更轻松地构建、部署和管理容器化应用。
架构层对比
从 vendor support 对比
OpenShift 和 Kubernetes 之间的一些区别