В enterprise-компаниях вместо ванильного Kubernetes часто стоит OpenShift — и разработчик, привыкший к kubectl и Ingress, попадает в мир oc, Routes и загадочных отказов «pod не может стартовать под root». Разберём, что OpenShift добавляет поверх Kubernetes и что из этого реально касается вас.

Что это

OpenShift — дистрибутив Kubernetes от Red Hat. Внутри — тот же Kubernetes (те же поды, деплойменты, сервисы, тот же API), но собранный в готовый продукт с поддержкой, интегрированной сборкой, безопасностью «из коробки» и веб-консолью. Аналогия: Kubernetes — ядро, OpenShift — дистрибутив вокруг него, как Ubuntu вокруг Linux.

Поэтому знание Kubernetes переносится напрямую: манифесты Deployment, Service, ConfigMap работают как есть. Отличия — в надстройках.

Что добавляет поверх Kubernetes

  • Routes вместо Ingress. Внешний доступ в OpenShift исторически делается через объект Route (со встроенным HAProxy-роутером), а не через Ingress. Свежие версии понимают и Ingress, но в существующих проектах вы почти всегда встретите Route.
  • Встроенный реестр и сборка (S2I). OpenShift умеет собирать образ из исходников через Source-to-Image: даёшь репозиторий — получаешь образ в его внутреннем реестре, без ручного Dockerfile. За это отвечают объекты BuildConfig и ImageStream.
  • Security Context Constraints (SCC). Главный источник сюрпризов. По умолчанию OpenShift запрещает контейнерам запускаться от root и назначает случайный UID. Образ, который на обычном Kubernetes работал под root, здесь падает — его нужно сделать «rootless»: не хардкодить UID, разрешить запись только в нужные каталоги.
  • oc и веб-консоль. CLI oc — надмножество kubectl (всё то же плюс OpenShift-специфика: oc new-app, oc login). Плюс развитая графическая консоль для деплоя и диагностики.
  • Projects вместо namespace. «Проект» в OpenShift — это namespace с дополнительными политиками доступа поверх.

Что это значит для разработчика

Если вы деплоите Spring Boot-сервис в OpenShift:

  • Образ должен быть rootless. Готовьте контейнер так, чтобы он работал под произвольным непривилегированным UID (не пишите в /, кладите файлы в каталоги с групповой записью). Это же — хорошая практика и для обычного Kubernetes.
  • Внешний доступ — через Route. Вместо Ingress создаёте Route на ваш Service (или пользуетесь oc expose).
  • Пробы, ресурсы, конфигурация — как в Kubernetes. readinessProbe, livenessProbe, лимиты CPU/памяти, ConfigMap/Secret — всё то же самое; здесь ничего переучивать не нужно.

Практический вывод: учите Kubernetes — он переносится в OpenShift на 90%. OpenShift-специфику (Routes, SCC, S2I) добираете точечно под конкретный кластер.

Коротко

  • OpenShift — дистрибутив Kubernetes от Red Hat: то же ядро, надстройки сверху и коммерческая поддержка.
  • Внешний доступ — через Route (встроенный роутер), а не только Ingress.
  • Умеет собирать образ из исходников (S2I, BuildConfig, ImageStream) и хранить его во встроенном реестре.
  • Security Context Constraints запрещают root и дают случайный UID — образ должен быть rootless, это частая причина падений при переезде.
  • oc — надмножество kubectl; манифесты Kubernetes работают как есть, переучиваться не нужно.

Что почитать дальше

  • Kubernetes: основы — поды, деплойменты и сервисы, на которых стоит OpenShift.
  • Деплой в Kubernetes — манифесты, Helm и rolling update.
  • Spring Boot в Kubernetes — пробы и конфигурация сервиса в кластере.