До событий прошлого года одной из основных платформ управления контейнерами была Red Hat OpenShift Container Platfrom. Ей пользовались компании сегмента Enterprise с высокими требованиями к функциональности и стабильности продукта, а также к уровню поддержки решения. Теперь продажи Red Hat, как и других западных решений, невозможны. Поэтому встает вопрос о выборе альтернатив.
Меня зовут Юрий Семенюков, я директор центра проектирования вычислительных комплексов «Инфосистемы Джет». С 2018 года занимаюсь развитием направления DevOps в части инфраструктуры под контейнерное окружение, руковожу проектными командами по внедрению платформ контейнеризации в Enterprise на разных дистрибутивах. В этом посте я расскажу, как крупные компании справляются с уходом западных коммерческих дистрибутивов Kubernetes.
Кто использовал Enterprise-решения?
В ноябре 2020 года «Инфосистемы Джет» совместно с CNews провели исследование «Проникновение технологий контейнеризации в IT-ландшафт крупных компаний». Мы опросили российские компании из ТОП-500 РБК: банки, промышленность, страховые компании, ритейлеры и др. Один из вопросов был: «Какие средства управления контейнерами использует ваша компания?»
Вот результат ответов на этот вопрос:
Видно, что два-три года назад лидирующим решением по управлению контейнерами среди отечественных компаний был опенсорсный Kubernetes в варианте on-premise инсталляции.
Что касается Enterprise-решений (подсвечено красным):
Это Red Hat OpenShift on-premise и другие вендорские решения на базе Kubernetes (Tanzu, Rancher и прочее), которые в сумме занимали 18%, то есть почти пятую часть рынка.
Вот данные по отраслям:
Интересно, что треть респондентов сказали, что не используют никакие средства управления контейнерами (подсвечено синим в следующем графике).
Сегодня при переходе на микросервисную архитектуру перед компаниями, которые не использовали платформы контейнеризации, встал вопрос: «Что делать?». Ведь если раньше можно было купить OpenShift и не знать проблем, то сейчас этого сделать нельзя.
Что делать?
На что заменить Enterprise Kubernetes, если это вообще возможно?
На мой взгляд, есть несколько вариантов:
Open Source Kubernetes (дефолтный вариант — про него я отдельно говорить не буду, сравним остальные варианты с ним)
OKD
Отечественные решения
Публичные облака, в которых есть Kubernetes
OKD
OKD — это опенсорсный upstream-вариант решения Red Hat OpenShift, который развивается силами комьюнити. OKD не поддерживается вендором и имеет ряд технологических нюансов, о которых поговорим чуть позже.
Почему «да»?
Если ставить Kubernetes из коробки, то в нем есть только сам Kubernetes. А в OKD есть много чего еще: он представляет собой собранную готовую платформу. Если Kubernetes — это фреймворк, который позволяет собирать определенный конструктор, то OKD — это уже вариант реализации этого конструктора. В нем присутствуют все необходимые компоненты, которые так или иначе всегда добавляются к кластеру Kubernetes, чтобы Kubernetes был применим для работы в продуктиве.
Кроме того, в состав OKD входит неизменяемая операционная система Immutable OS. В Red Hat она называлась Red Hat CoreOS, в OKD это Fedora CoreOS. Эта ОС практически полностью исключает необходимость администрирования, являясь по сути частью общего appliance вместе с самим OKD.
OVNKubernetes / Multus / SR-IOV
В Kubernetes, как известно, никакие сетевые плагины «из коробки» не идут. Самый популярный вариант — наверное, Calico. Но нам на одном из проектов для решения задачи заказчика он не подошел, поэтому мы использовали другие сетевые плагины — OVNKubernetes, Multus и SR-IOV (последний потребовался, потому что на нашем проекте используется большое количество сетевых подключений на физическом уровне). Эти плагины могут быть выбраны при установке и настройке OKD, что сокращает затраты на их конфигурирование.
Assisted service / Hive
Мы использовали концепцию единого централизованного management-кластера OKD, из которого разворачиваются небольшие edge-кластеры OKD в отдаленных локациях.
Взяли Assisted service — функционал, который является дополнительной оберткой вокруг OpenShift-инсталлера. Он позволяет разворачивать «клиентские» кластеры из management-кластера на базе конфигурации, подаваемой на вход. Это довольно удобно, когда таких кластеров нужно развернуть много (как у нас), или, когда делать это нужно периодически. У нас некоторые edge-кластеры жили на Bare Metal, поэтому мы поверх использовали еще и Hive, который позволяет делать такие развертывания.
Специфичные разработки вендоров
Есть довольно большое количество вендорских разработок, которые изначально сделаны под OpenShift.
Мы использовали фреймворк мониторинга OpenStack среды, который называется STF. Это очень специфичная, узконаправленная штука, которая адаптирована под OpenShift и, соответственно, работает и в OKD.
Можно ли было всё это сделать на базе обычного Kubernetes? Безусловно. Всё из описанного можно было бы настроить, «прикрутить» или реализовать так или иначе на базе «ванильного» кластера. Вопрос во времени и ресурсах. По самым грубым оценкам, нам удалось сократить время реализации проекта примерно на полгода за счет использования OKD.
Поддерживаемые платформы
При разговорах о замене вендорских дистрибутивов Kubernetes важно отметить, что импортозамещать придется не только Kubernetes, но и всю ИТ-платформу и всю ИТ-инфраструктуру. Самым популярным решением по виртуализации является VMware vSphere, который формально сейчас для нас недоступен. Для многих заказчиков актуален вопрос: что делать с виртуализацией? Компании активно начинают смотреть в сторону отечественных решений, в основном на oVirt.
Возвращаясь к выбору OKD, нужно сказать, что в installer-provisioned инсталляции OКD нативно поддерживает oVirt как провайдера инфраструктуры. В целом, список поддерживаемых провайдеров OKD следующий:
VMware vSphere
OpenStack
oVirt
Bare Metal
Их поддержка при инсталляции означает, что OKD может самостоятельно подготовить инфраструктуру, поверх которой она будет работать: нарезать виртуалки, сети, сделать балансировщики и прочее. На Kubernetes это пришлось бы делать руками, что всегда занимает довольно большое количество времени.
Почему «нет»?
Если в предыдущей части статьи вам показалось, что всё это — скрытая реклама OKD, то это не так. И сейчас я расскажу, в каких случаях он не подойдет и когда применять его не нужно или нецелесообразно.
OKD != OCP
OKD — это не OpenShift. У него не будет поддержки от вендора, так как это опенсорс.
Операторы OKD
У OKD нет большого количества операторов в комплекте поставки, которые идут в составе OpenShift. Например, нам нужно было использовать «джентельменский набор» операторов:
Logging Operator
Elasticsearch Operator
NMState Operator
А также дополнительно еще два для определенного проекта:
Performance Addon Operator
SRIOV Operator
Все эти операторы есть в OpenShift, они доступны по ключу для тех пользователей, кто купил подписку на ПО. А вот в OKD их приходится доставлять вручную. По сути, вы берете что-то из открытых источников, разных каталогов и внедряете в прод на свой страх и риск. Про сертификацию и проверки на закладки можно забыть.
Вот список некоторых распространенных доступных и недоступных операторов для OKD (на момент написания статьи):
Currently Unavailable
Available in Community Catalog
Available in Upstream Catalog
Нюансы upstream
На одном из проектов нам нужно было обновить версию OKD 4.8 на 4.10. При обновлении оказалось, что довольно сильно изменилась версия ядра Fedora CoreOS, на которую у нас были завязаны низкоуровневые драйверы сетевых адаптеров, и вся наша сетевая конфигурация благополучно перестала работать. Такие фокусы с совместимостью — обычно не то, чего ожидаешь от Enterprise-решения.
В итоге нам пришлось выпиливать из-под OKD ее нативную операционку и вкатывать в CentOs CoreOS. Такая замена подобна игре в Дженгу: с самого низа мы выбивали один кубик и незаметно заменяли его другим. Это тот еще фокус, повторять который лишний раз не хочется.
Как заменить OCP на OKD?
Самый лучший вариант — полная переустановка платформы. Но можно сделать это и быстрее, используя всего лишь одну команду:
oc patch clusterversion/version
--patch
'{"spec":{"upstream":"https://amd64.origin.releases.ci.openshift.org/graph"}}’
--type=mergeНужно только указать источник на репозиторий, откуда можно взять дистрибутивы и подменить инсталляцию. Так вы получите у себя OKD вместо OpenShift без повторного деплоя.
Но опять есть нюансы. Вы получите смену только дистрибутива и встроенных операторов. Всё, что вы добавили в OpenShift, например, каталог операторов, не поменяется. То есть работоспособность всего остается под вопросом. Так что используйте лайфхак с осторожностью.
Выводы
Если вы с OpenShift не хотите уходить на «ванильный» кубер, то, безусловно, OKD — один из основных кандидатов. Жить с ним можно, учитывая особенности.
OpenShift как в России, так и во всем мире является лидирующим дистрибутивом Kubernetes в Enterprise. Поэтому можно говорить о том, что он уже стал стандартом индустрии. Это решение имеет наибольшую экосистему партнеров, экспертизу, комьюнити, базу знаний и прочее. И в работе с OKD это очень сильно помогает.
Но при этом никуда не денутся сюрпризы опенсорса. В частности, придется создавать свой каталог операторов вручную, бороться с багами при обновлениях и т. д.
Отечественные решения
На рынке отечественных коммерческих дистрибутивов ситуация довольна благоприятная. Во-первых, есть уже существующие стабильные решения, проверенные временем. Во-вторых, за последнее время появилось как минимум несколько новых игроков, а значит, конкуренция будет большая.
Deckhouse от компании Флант
Мы хорошо знакомы с этим решением. В его основе — тот самый «ванильный» Kubernetes: не fork, а именно основной вариант. Коллеги добавили к Kubernetes определенный набор компонентов:
Автоматизированная инсталляция
CNI-плагины
Ingress, load balancing
Логирование
Мониторинг с готовыми метриками и дашбордами
Автоматическое обновление
Управление сертификатами
Поддержка on-prem и облаков
Поддержка «закрытых» контуров
Используя их, вендор сделал платформу, которая позволяет превратить Kubernetes в production-ready кластер. В этом наборе в наших реалиях очень важен последний пункт — поддержка «закрытых» контуров. У большого количества заказчиков в проде нет выхода в интернет, и, когда нужно что-то инсталлировать в production-контуре, важно уметь делать это без выхода «наружу». С Kubernetes это та еще задачка. Deckhouse поддерживает это из коробки.
И самое главное: поскольку Deckhouse — это вендорский продукт, то команда Фланта (сама либо через партнеров) обеспечивает поддержку, а также формирует комьюнити, исправляет баги, слушает заказчиков и улучшает Road Map.
«Штурвал» от компании «Лаборатория Числитель»
Если у Deckhouse есть кейсы успешного внедрения и довольно много клиентов, то «Штурвал» — более молодое решение. Оно только в 2022 году появилось на рынке. Вендором является компания «Лаборатория Числитель». Концепция в принципе та же самая: Kubernetes плюс определенный набор важных компонентов:
Единый Management cluster
Сканирование конфигурации на соответствие параметрам CIS Benchmark
CNI-плагины
Ingress, load balancing
Логирование
Мониторинг с готовыми метриками
Автоматическое обновление
Управление сертификатами
Поддержка on-prem и частных облаков
Поддержка «закрытых» контуров
Из интересного в рамках этого решения — это концепция управления из единого кластера. Сначала вы разворачиваете централизованный кластер «Штурвала» — Management cluster, в котором нет полезной пользовательской нагрузки. Он используется только для управления последующими клиентскими кластерами, которые из Management cluster можно разворачивать за один клик. Не придется использовать никаких консолей и конфиг-файлов. Прямо в красивом графическом интерфейсе можно задать минимальные параметры и развернуть кластер.
Такие кластеры легко и удобно эксплуатировать. У команды эксплуатации появляется единая точка управления всеми кластерами и контурами, а их может быть очень много. Так значительно экономятся ресурсы на управление всем ландшафтом среды Kubernetes.
Отечественные платформы заточены именно на on-premise. В публичных облаках есть свои предложения по Kubernetes (Managed Kubernetes), но Enterprise - компании используют публичные облака довольно ограниченно. Поэтому рассмотренные решения являются хорошей заменой OpenShift, это стабильные зрелые продукты, готовые к применению в production.
Надеюсь, по итогам этой статьи стало чуть понятнее, какие пути и препятствия ждут вас в каждом из вариантов. Пишите в комментариях, что бы выбрали вы?
Желающих присоединиться к сообществу DevOps приглашаю в Telegram-канал. Здесь мы с командой обсуждаем вопросы разработки, безопасности и эксплуатации, делимся лайфхаками и лучшими практиками.