这些应用程序被编程为使用 kubernetes API。
我们是否应该假设从 kubernetes 的角度来看，openshift 容器平台符合 openshift origin（和 kubernetes）的所有标准？
背景
随附的兼容性测试云原生应用程序可能包含一个大型矩阵。看起来，作为基线，如果 OCP 是一个纯 kubernetes 发行版，带有附加组件，那么只要您只使用核心 kubernetes 功能，对其进行测试就很简单。
另外，如果发布支持 OCP 的应用意味着您必须测试 OCP，这对我来说意味着 (1) 该应用使用 OCP 功能或 (2) 该应用使用可能无法在 OCP 中正常工作的 kube 功能，这应该被认为是一个错误。
【问题讨论】：
标签： kubernetes openshift redhat
在实践中，您应该能够将 OpenShift Container Platform (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 对象的自动映射，所以我相信 Ingress 应该可以工作，即使 OpenShift 实际上使用 Routes 及其 haproxy 路由器设置实现了 Ingress。
显然还有其他差异。 OpenShift 有 DeploymentConfig，因为 Kubernetes 最初从未有过 Deployment。同样，您可以使用 DeploymentConfig 做一些您不能用 Deployment 做的事情，但支持来自 Kubernetes 的 Deployment 对象。 DeploymentConfig 的一个不同之处在于它如何与 OpenShift 中的 ImageStream 对象一起工作，这些对象在 Kubernetes 中不存在。坚持使用 Deployment/StatefulSet/DaemonSet，不要使用在 Kubernetes 没有这些功能时创建的 OpenShift 对象，你应该没问题。
请注意，OpenShift 对某些资源类型采取了保守的方法，因此默认情况下可能不会启用它们。这适用于仍被视为 alpha 或处于早期开发阶段并可能发生变化的事物。即使使用普通的 Kubernetes，你也应该避免仍在开发中的东西。
总而言之，对于核心 Kubernetes 位，OpenShift 已通过针对 Kubernetes 的 CNCF 测试的一致性验证。所以使用它所涵盖的内容，你应该没问题。
【讨论】：