从kubernetes的角度来看,在OpenShift容器平台(OCP)上进行测试是否等同于在OpenShift源代码上进行测试?

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

在比较这两个与简单的库伯内茨有一些事情你需要记住。

root 因为它们在默认服务帐户下运行,而该帐户没有此类权限。该默认服务也不能访问restapi。普通用户没有权限来启用运行以下映像的能力: 根

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

这并不意味着您不能让它工作,它只是意味着您需要采取额外的步骤,以便您或您的应用程序被授予额外的权限来执行它需要的操作。

这是人们遇到问题的主要领域,这是因为OpenShift被设置为更安全的开箱即用,以适应多用户的多租户环境,甚至可以将不同的应用程序分开,这样它们就不会相互干扰。

接下来值得一提的是安格尔斯。当Kubernetes第一次出现的时候,它没有入口的概念。为了填补这个漏洞,OpenShift实现了路由的概念。Ingres只是在很久之后才出现的,并且是基于OpenShift中使用Routes所做的部分工作。也就是说,有些事情你可以做的路线,我相信你仍然不能做的入口。

总之,显然,如果使用Routes,这只在OpenShift上有效,因为普通的Kubernetes集群只有入口。如果使用Ingress,则需要使用OpenShift 3.10或更高版本。在3.10中,有一个入口到路由对象的自动映射,所以我相信入口应该可以工作,即使OpenShift实际上使用Routes和它的haproxy路由器设置来实现入口。

显然还有其他区别。OpenShift有DeploymentConfig,因为Kubernetes最初从未进行过部署。同样,您可以使用DeploymentConfig执行一些部署无法完成的操作,但是支持Kubernetes的部署对象。DeploymentConfig的一个不同之处在于它如何处理OpenShift中的ImageStream对象,而这些对象在Kubernetes中不存在。坚持使用Deployment/StatefulSet/DaemonSet,不要使用OpenShift对象,这些对象是在Kubernetes没有这些特性的情况下创建的。

请注意,尽管OpenShift对某些资源类型采取了保守的方法,因此默认情况下可能不会启用它们。这是为了那些仍然被视为alpha的事物,或者是处于非常早期的发展中并且可能会发生变化的事物。即使使用简单的Kubernetes,也应该避免那些仍在开发中的东西。

也就是说,对于核心Kubernetes位,OpenShift通过针对Kubernetes的CNCF测试进行了一致性验证。所以用上面提到的,你应该没事。

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