На практике вы должны понимать, что OpenShift Container Platform (OCP) совпадает с OKD (ранее известной как Origin). Это потому, что это фактически одно и то же программное обеспечение и настройка.
Сравнивая оба этих понятия с простыми Кубернетами, нужно помнить о нескольких вещах.
Распределение OpenShift Kubernetes настроено как мультитенантная система с четким различием между обычными пользователями и администраторами. Это означает, что RBAC настроен так, что обычный пользователь ограничен в том, что он может делать из коробки. Обычный пользователь не может, например, создать произвольные ресурсы, которые влияют на весь кластер. Они также не могут запускать образы, которые будут работать только в том случае, если они запускаются как root, поскольку они запускаются под учетной записью службы по умолчанию, которая не имеет таких прав. Эта служба по умолчанию также не имеет доступа к REST API. Обычный пользователь не имеет прав, позволяющих запускать такие образы, как root. Пользователь, который является администратором проекта, может разрешить приложению использовать REST API, но то, что оно может делать через REST API, будет ограничено проектом / пространством имен, в котором оно выполняется.
Итак, если вы разрабатываете приложение в Kubernetes, где вы ожидаете, что у вас есть полный административный доступ, и вы можете создавать любые ресурсы, которые вам нужны, или предполагаете, что в вашем распоряжении нет RBAC / SCC, ограничивающего ваши возможности, вы могут возникнуть проблемы с запуском.
Это не значит, что вы не можете заставить его работать, это просто означает, что вам нужно предпринять дополнительные шаги, чтобы вы или ваше приложение получили дополнительные привилегии для выполнения того, что ему нужно.
Это основная область, в которой у людей возникают проблемы, и это потому, что OpenShift настроен так, чтобы быть более защищенным из коробки, чтобы соответствовать многопользовательской среде для многих пользователей, или даже для разделения различных приложений, чтобы они не могли мешать работе друг друга.
Следующее, что стоит упомянуть, это Ingress. Когда Kubernetes впервые вышел, у него не было понятия Ingress. Чтобы заполнить эту дыру, OpenShift реализовал концепцию маршрутов. Ingress появился намного позже и был основан на части того, что было сделано в OpenShift с Routes. Тем не менее, есть вещи, которые вы можете сделать с Routes, но я думаю, что вы все еще не можете сделать с Ingress.
В любом случае, очевидно, что если вы используете Routes, это работает только в OpenShift, так как обычный кластер Kubernetes имеет только Ingress. Если вы используете Ingress, вам нужно использовать OpenShift 3.10 или новее. В 3.10 имеется автоматическое сопоставление Ingress с объектами Route, поэтому я считаю, что Ingress должен работать, даже если OpenShift фактически реализует Ingress под прикрытием, используя Routes и настройку своего маршрутизатора haproxy.
Очевидно, есть и другие различия. OpenShift имеет DeploymentConfig, потому что у Kubernetes изначально никогда не было Deployment. Опять же, есть вещи, которые вы можете сделать с DeploymentConfig, которые вы не можете сделать с помощью Deployment, но объект Deployment из Kubernetes поддерживается. Одно из отличий DeploymentConfig состоит в том, как он работает с объектами ImageStream в OpenShift, которых нет в Kubernetes. Придерживайтесь Deployment / StatefulSet / DaemonSet и не используйте объекты OpenShift, которые были созданы, когда у Kubernetes не было таких функций, с вами все будет в порядке.
Обратите внимание, что OpenShift использует консервативный подход к некоторым типам ресурсов, поэтому по умолчанию они могут быть не включены. Это относится к вещам, которые все еще рассматриваются как альфа или находятся на очень ранней стадии разработки и подвержены изменениям. Вам следует избегать вещей, которые все еще находятся в разработке, даже если вы используете простой Kubernetes.
Тем не менее, для основных битов Kubernetes, OpenShift проверяется на соответствие тестам CNCF для Kubernetes. Так что используйте то, что покрыто этим, и вы должны быть в порядке.