在OpenShift容器平台(OCP)上的测试是否等同于从kubernetes角度对Openshift原产地的测试？

Question

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

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

背景

兼容性测试提供的云本地应用程序可以包含一个大型矩阵。似乎，作为一个基线，如果OCP是一个纯kubernetes发行版，并添加了ons，那么对它进行测试就很简单了，只要您只使用核心kubernetes特性。

或者，如果在OCP上提供支持的应用程序意味着您必须测试OCP，对我来说，这意味着(1)应用程序使用OCP功能，或者(2)应用程序使用可能在OCP中不能正确工作的kube功能，这应该被认为是一个错误。

Answer 1

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

在将这两者与普通的库伯奈特进行比较时，有几件事你需要记住。

Kubernetes的OpenShift发行版是作为一个多租户系统设置的，它明确区分了普通用户和管理员。这意味着RBAC被设置，这样普通用户就会被限制在他们可以做的事情上。例如，普通用户不能创建影响整个集群的任意资源。它们也不能运行只有以root的形式运行的映像，因为它们运行在默认的服务帐户下，而默认服务帐户没有这样的权限。该默认服务也无法访问REST。普通用户没有权限来启用像root这样的映像。作为项目管理员的用户可以允许应用程序使用REST，但是它通过REST所能做的事情将被限制在它运行的项目/命名空间中。

因此，如果您在Kubernetes上开发一个应用程序，您希望可以完全访问管理，并且可以创建您想要的任何资源，或者假设没有RBAC/SCC来限制您所能做的事情，那么运行它就会有问题。

这并不意味着您不能让它工作，它只是意味着您需要采取额外的步骤，以便您或您的应用程序获得额外的特权来完成它所需要的工作。

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

下一件值得一提的事是“娜妞”。当库伯奈特斯第一次出来的时候，它根本就没有进题的概念。为了填补这个漏洞，OpenShift实现了路线的概念。入口是在很晚的时候才来的，部分是基于OpenShift的路线。尽管如此，有些事情你可以做的路线，我相信你仍然不能做的事，因为她。

无论如何，很明显，如果您使用路由，那么只在OpenShift上工作，因为普通的Kubernetes集群只有Ingress。如果您使用OpenShift 3.10或更高版本，则需要使用它。在3.10中，有一个自动映射到路由对象，所以我认为即使OpenShift实际上在使用路由的掩护下实现了In宿，以及它的haproxy路由器设置，它也应该能工作。

显然还有其他的不同之处。OpenShift有DeploymentConfig，因为Kubernetes最初从未进行过部署。同样，您可以使用DeploymentConfig做一些部署不能做的事情，但是支持来自Kubernetes的部署对象。DeploymentConfig的一个不同之处在于它如何与OpenShift中的ImageStream对象一起工作，而库伯内特斯中并不存在这些对象。坚持使用Deployment/StatefulSet/DaemonSet，不要使用在Kubernetes没有这样的特性时创建的OpenShift对象，您应该会很好。

但是请注意，对于某些资源类型，OpenShift采取了一种保守的方法，因此在默认情况下可能不会启用它们。这对于那些仍然被认为是alpha的事物来说，或者在其他方面处于非常早期的发展和可能的变化中。即使使用朴素的Kubernetes，您也应该避免仍在开发中的东西。

总之，对于核心Kubernetes位，OpenShift被验证是否符合CNCF对Kubernetes的测试。所以，使用它所涵盖的内容，你应该会没事的。

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