OpenShift: улучшенный Kubernetes или переплата за техподдержку?
Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! В прошлых постах мы разобрали особенности Docker на разных системах и его не менее интересного собрата Podman от Red Hat. Сегодня поговорим о ещё одном творении той же компании — OpenShift, который позиционируется, как «корпоративная» версия Kubernetes. Но так ли всё радужно, как рассказывают на презентациях?
Маркетинг vs реальность
Red Hat позиционируют OpenShift, как корпоративную версию Kubernetes с расширенными возможностями безопасности и управления. Ключевым компонентом предложения является корпоративная поддержка, которая составляет значительную часть стоимости продукта. Однако на практике эффективность этой поддержки может варьироваться — иногда процесс решения проблем занимает больше времени, чем можно было бы ожидать от enterprise-решения.
Помните, как в посте про Podman мы обсуждали, что Red Hat любит изобретать велосипед, чтобы потом продавать его как революционное средство передвижения? С OpenShift история очень похожая: берём отлично работающий open-source продукт, добавляем немного корпоративного лоска, заворачиваем в красивую обёртку — и вот вам «энтерпрайз решение».
«Enterprise» такой enterprise
Рассмотрим циклы обновлений обеих платформ. Kubernetes следует установленному графику с выпуском новой минорной версии каждые 15 недель (около 3.5 месяцев), как указано в официальной документации. OpenShift также придерживается регулярного цикла обновлений, выпуская примерно 3–4 минорных релиза в год.
Однако ключевое различие заключается в модели поддержки. В случае с OpenShift клиенты могут выбрать между двумя уровнями расширенной поддержки (Standard и Premium), что дает им доступ к более длительным периодам поддержки версий и специализированной технической помощи. При этом цикл обновлений OpenShift ориентирован на обеспечение стабильности enterprise-окружений, где частые обновления могут быть нежелательны.
Однако обновления далеко не всегда проходят гладко. В сообществе Kubernetes если что-то пошло не так, вы можете быстро найти решение или откатиться назад. С OpenShift же вы оказываетесь в ситуации «позвоните в поддержку и ждите». И хорошо, если эта поддержка действительно поможет, а не начнёт гонять вас по скриптам из базы знаний, которые вы уже сами прогнали трижды.
Безопасность по-краснофедоровски
А теперь давайте поговорим о главном козыре OpenShift — пресловутой «безопасности из коробки». Red Hat активно продвигает этот аспект на каждой презентации, расписывая предустановленные политики безопасности и встроенные механизмы защиты. Но на практике эта «безопасность из коробки» часто превращается в настоящий кошмар для разработки и эксплуатации.
OpenShift поставляется с предустановленными строгими политиками безопасности, которые являются важным преимуществом для корпоративных клиентов. По умолчанию контейнеры работают с ограниченными правами: отсутствует возможность записи в файловую систему, использование определенных портов ограничено, запуск от root запрещен. Такой подход реализует принцип «безопасность по умолчанию» (secure by default), что критически важно для enterprise-среды.
При работе с legacy-приложениями или специфическим ПО может потребоваться ослабление некоторых ограничений. OpenShift предоставляет такую возможность, но требует явного документирования и обоснования подобных исключений, что соответствует корпоративным практикам управления безопасностью.
То, что в обычном Kubernetes делается простым редактированием YAML-файла, здесь требует погружения в дебри Security Context Constraints, особых разрешений и сложных конфигураций. А документация по этим настройкам часто настолько запутанная, что проще написать приложение заново, чем разобраться, почему оно не работает с текущими политиками безопасности.
Отдельная головная боль — это работа с сетевыми политиками. OpenShift использует собственный SDN-плагин, который, по заверениям Red Hat, безопаснее и лучше стандартных решений. Но попробуйте настроить нестандартную маршрутизацию или специфическую конфигурацию сети — вы внезапно обнаружите, что документация неполная, примеров мало, а поддержка отвечает стандартными отписками из базы знаний.
Экосистема и вендорский замок
Red Hat построила вокруг OpenShift целую экосистему и сделала это очень умело. Многие компании понимают, что они попали в вендорский замок, только когда становится слишком поздно. Всё начинается очень невинно: вам предлагают использовать их инструменты, потому что они «лучше интегрируются» и «безопаснее». CRI-O вместо containerd, их container registry вместо стандартного, их версии всех популярных инструментов. И вот вы уже по уши в их экосистеме, а выбраться без серьёзных затрат времени и ресурсов практически невозможно.
Red Hat развивает собственную экосистему инструментов контейнеризации. CRI-O, являющийся проектом CNCF (Cloud Native Computing Foundation), используется как runtime для контейнеров. Для работы с контейнерами на уровне хоста предлагается Podman, а для сборки образов есть Buildah. Что касается сетевого взаимодействия, OpenShift использует свой SDN-плагин.
Стоит также отметить, что в современном Kubernetes по умолчанию используется containerd, а не Docker. Последний, как и Podman, сейчас в основном применяется на этапе разработки и сборки контейнеров. При этом интеграция сторонних инструментов в экосистему OpenShift может потребовать дополнительных усилий по настройке и тестированию.
Отдельного разговора заслуживает подход Red Hat к документации и «лучшим практикам». Они умудряются создать впечатление, что их способ — единственный правильный, а все остальные либо небезопасны, либо «не соответствуют корпоративным стандартам». При этом их «лучшие практики» удивительным образом всегда сводятся к использованию максимального количества их же продуктов. Нужен мониторинг? Конечно же, вам предложат их стек. Требуется логирование? У них есть отличное решение. Ищете service mesh? Вот вам их версия Istio.
Санкции, санкции, кругом одни санкции
А теперь поговорим о том, о чём в Red Hat предпочитают вообще не упоминать — о санкционных рисках. В текущих реалиях использование OpenShift в России превратилось в своеобразную русскую рулетку. Ваша лицензия может работать сегодня, но завтра Red Hat внезапно решает, что работать с российскими компаниями больше не будет. И что тогда? Правильно, вы останетесь с устаревшей версией и без поддержки, за которую заплатили весьма внушительные суммы.
В отличие от многих других enterprise-решений, которые хотя бы имеют открытые аналоги, с OpenShift всё гораздо сложнее. Это целая экосистема, и если вы в неё глубоко интегрировались, выход может оказаться крайне болезненным процессом. Особенно, если это произойдёт не по вашей инициативе, а по решению какого-нибудь санкционного комитета, который даже не будет утруждать себя предварительным уведомлением.
А что же взамен?
Обычный Kubernetes может не иметь такого красивого веб-интерфейса и встроенной поддержки всего на свете, но у него есть куда более важные преимущества. В первую очередь, это частота обновлений и скорость реакции на появление новых уязвимостей. Пока OpenShift неспешно готовит свой очередной релиз раз в несколько месяцев, сообщество Kubernetes успевает выпустить несколько обновлений, закрывающих потенциальные угрозы.
За Kubernetes стоит огромное сообщество разработчиков и инженеров, которые не только быстро находят и исправляют проблемы, но и создают множество полезных инструментов и расширений. И что особенно важно в текущей ситуации — Kubernetes никак не зависит от политической обстановки и санкций. Никто не отключит вам доступ к обновлениям из-за очередного обострения международных отношений.
Конечно, вам придётся самостоятельно настраивать некоторые вещи, которые в OpenShift идут «из коробки». Но давайте будем честными — эта «коробочность» OpenShift часто оказывается палкой о двух концах. Когда вы сами настраиваете свою инфраструктуру, вы точно знаете, как она работает, и можете быстро починить, если что-то сломается. К тому же, на разницу в стоимости между OpenShift и обычным Kubernetes можно нанять нескольких толковых DevOps-инженеров, которые настроят вам всё не просто «как в OpenShift», а именно так, как нужно вашему бизнесу.
Суровая правда жизни
В теории OpenShift должен экономить время и деньги за счёт готовых решений и корпоративной поддержки. На практике же ситуация складывается совсем иначе: вы платите значительно больше за базовую функциональность, получаете обновления реже, чем пользователи обычного Kubernetes, и при этом постоянно находитесь в зависимости от настроения Red Hat и общей геополитической обстановки.
Что особенно обидно — при возникновении серьёзных проблем часто всё равно приходится разбираться самостоятельно. Потому что поддержка либо отвечает слишком долго, либо предлагает решения, которые явно взяты из базы знаний без понимания вашей конкретной ситуации. А когда вы наконец находите решение сами, оказывается, что оно «не соответствует рекомендуемым практикам» и может привести к проблемам при следующем обновлении.
И если посмотреть на долгосрочную перспективу, то инвестиции в развитие собственной экспертизы в Kubernetes оказываются куда более выгодными, чем постоянная зависимость от проприетарных решений. Потому что в конечном счёте важнее не красивый веб-интерфейс и обещания «корпоративного уровня поддержки», а реальная возможность эффективно управлять своей инфраструктурой и быстро решать возникающие проблемы.
А как у вас обстоят дела с выбором платформы для оркестрации контейнеров? Особенно интересно услышать от тех, кто работал с OpenShift в России после начала санкций. Делитесь опытом в комментариях!
