此应用程序被编程为使用kubernetes API。
从kubernetes的角度来看，我们是否应该假设openshift容器平台符合openshift起源（和kubernetes）所遵循的所有标准？
背景
兼容性测试附带的云本机应用程序可以包含一个大型矩阵。似乎，作为一个基准，如果OCP旨在成为具有附加功能的纯kubernetes发行版，那么只要您仅使用核心kubernetes功能，对它进行测试都是微不足道的。
或者，如果要发布支持OCP的应用程序意味着您必须测试OCP，则对我而言意味着（1）该应用程序使用OCP功能或（2）该应用程序使用kube功能，这些功能可能无法在OCP中正常工作，应该被认为是错误。
答案 0 :(得分：5)
在实践中，您应该可以将OpenShift容器平台（OCP）视为与OKD（以前称为Origin）相同。这是因为它实际上是相同的软件和设置。
在将它们与普通Kubernetes进行比较时，需要牢记一些事情。
Kubernetes的OpenShift发行版设置为多租户系统，在普通用户和管理员之间有明显的区别。这意味着已设置RBAC，以便限制普通用户的开箱即用功能。例如，普通用户无法创建影响整个群集的任意资源。他们也无法运行仅以root身份运行的映像，因为它们是在没有这种权限的默认服务帐户下运行的。该默认服务也无权访问REST API。普通用户没有特权来运行诸如root之类的图像。作为项目管理员的用户可以允许应用程序使用REST API，但是通过REST API可以执行的操作将仅限于运行它的项目/名称空间。
因此，如果您希望在Kubernetes上开发应用程序，并且期望该应用程序具有完全的管理员访问权限，并且可以创建所需的任何资源，或者假设没有RBAC / SCC来限制您的工作范围，在运行时可能会有问题。
这并不意味着您无法使其正常运行，仅意味着您需要采取额外的步骤，以便您或您的应用程序被授予额外的特权来执行所需的工作。
这是人们遇到问题的主要领域，这是因为OpenShift设置为开箱即用，更加安全，以适合许多用户的多租户环境，甚至可以分隔不同的应用程序，从而使他们不会干扰彼此。
接下来值得一提的是Ingress。当Kubernetes首次问世时，它没有Ingress的概念。为了填补这一空白，OpenShift实施了路线的概念。 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测试。因此，请使用其中涵盖的内容，您应该可以。