是否在测试OpenShift容器平台(OCP)等同于从kubernetes角度测试OpenshiftOrigin？

这个应用程序被编程为使用kubernetes API.

从kubernetes的角度来看,我们是否应该假设openshift容器平台符合开放式起源(和kubernetes)的所有标准？

背景

供应的兼容性测试云原生应用程序可以包含大型矩阵.作为一个基线,似乎OCP是一个纯粹的kubernetes发行版,加上ons,然后对它进行测试是微不足道的,只要你只使用核心kubernetes特性.

或者,如果在OCP上运送支持OCP的应用程序意味着您必须测试OCP,那对我来说意味着(1)应用程序使用OCP功能或(2)应用程序使用可能无法在OCP中正常工作的kube功能,这应该是一个被认为是一个bug.

在实践中,您应该能够将OpenShift容器平台(OCP)视为与OKD(以前称为Origin)相同.这是因为它实际上是相同的软件和设置.

将这两者与普通的Kubernetes进行比较时,您需要记住一些事项.

Kubernetes的OpenShift发行版被设置为多租户系统,在普通用户和管理员之间有明显的区别.这意味着建立RBAC,以便普通用户可以开箱即用.普通用户不能创建影响整个集群的任意资源.它们也无法运行仅在运行时运行的图像,root因为它们在没有此类权限的默认服务帐户下运行.该默认服务也无法访问REST API.普通用户没有权限启用运行此类图像的功能root.作为项目管理员的用户可以允许应用程序使用REST API,但是它可以通过REST API执行的操作将仅限于它运行的项目/命名空间.

因此,如果您在Kubernetes上开发一个应用程序,您希望您拥有完全的管理员访问权限,并且可以创建您想要的任何资源,或者假设没有RBAC/SCC可以限制您可以执行的操作,那么您可能会遇到问题让它运行.

这并不意味着你不能让它工作,它只是意味着你需要采取额外的步骤,以便你或你的应用程序被授予额外的权限,以满足它的需要.

这是人们遇到问题的主要领域,这是因为OpenShift设置为开箱即用,以适应许多用户的多租户环境,甚至分离不同的应用程序,以便它们不会相互干扰.

接下来值得一提的是Ingress.当Kubernetes第一次出现时,它没有Ingress的概念.为了填补这个漏洞,OpenShift实现了Routes的概念.Ingress只是在很晚才出现,并且基于OpenShift with Routes所做的部分工作.也就是说,你可以用Routes做些事情,我相信你仍然无法使用Ingress.

无论如何,显然,如果你使用Routes,那只适用于OpenShift,因为普通的Kubernetes集群只有Ingress.如果您使用Ingress,则需要使用OpenShift 3.10或更高版本.在3.10中,有一个Ingress到Route对象的自动映射,所以我相信即使OpenShift使用Routes及其haproxy路由器设置实际实现了Ingress,Ingress仍然可以工作.

显然还有其他差异.OpenShift有DeploymentConfig,因为Kubernetes从未进行过部署.您可以使用DeploymentConfig执行某些操作,而不能使用Deployment,但支持Kubernetes的Deployment对象.与DeploymentConfig的一个区别是它如何与OpenShift中的ImageStream对象一起工作,这在Kubernetes中不存在.坚持使用Deployment/StatefulSet/DaemonSet并且不要使用在Kubernetes没有这些功能时创建的OpenShift对象,你应该没问题.

请注意,OpenShift对某些资源类型采取保守的方法,因此默认情况下不启用它们.这适用于仍被视为alpha版本的内容,或者处于非常早期开发状态且可能发生变化的内容.即使使用普通的Kubernetes,也应该避免仍在开发中的东西.

总而言之,对于核心Kubernetes位,OpenShift经过验证,符合Kubernetes的CNCF测试.所以使用那个涵盖的内容你应该没问题.

https://www.cncf.io/certification/software-conformance/