Будущее Kubernetes в России: как (и чем) заменять оркестрацию контейнеров

ММ: Сегодня мы хотим обсудить ту ситуацию, которая возникла после 24 февраля. До этого рынок коммерческих платформ контейнеризации был поделен между несколькими иностранными вендорами (Red Hat OpenShift, Rancher), а кроме того, был вариант использования Vanilla Kubernetes или облачных сервисов.

После 24 февраля ситуация кардинально поменялась. Большинство вендоров приостановили свою деятельность на территории РФ, и компании, которые использовали эти платформы, столкнулись с рядом ограничений. Прежде всего, это отсутствие вендорской поддержки, невозможность получения обновлений.

Встает вопрос: по какому пути дальше двигаться? Продолжать с текущей платформой? Да, она осталась без поддержки, но пока работает. Какие риски у этого варианта? Может быть, стоит перейти на Vanilla Kubernetes и самостоятельно собрать платформу контейнеризации под себя? А может, посмотреть на российские решения? Или перейти в облака и передать часть работы облачному провайдеру?

Такими вопросами мы задались и решили пригласить Павла, потому что у его компании очень крутой опыт. У них был OpenShift, и в марте этого года нужно было решать, что делать дальше. Павел сегодня расскажет, какой путь выбрали в компании и почему именно такой, поделится нюансами, на которые стоит обратить внимание.

Но для начала давай немного поговорим про возможные варианты.

Сценарий номер один – остаться на зарубежной платформе без вендорской поддержки. Какие здесь есть риски, ограничения и кому, на твой взгляд, стоит или не стоит действовать по такому сценарию. Почему вы его не выбрали?

ПЛ: Хороший пример – наш партнер, большой банк, у которого есть и пока остается OpenShift. Именно поэтому он есть и у нас, мы должны были быть полностью технологически совместимы. Но банк, как большой авианосец, не может развернуться на месте – сразу поменять всю платформу контейнеризации. Крупные компании – именно тот случай, когда надо выбирать первый сценарий. Понятно, какие варианты возможны – по максимуму получить экспертизу; если у самих ее нет, ограничить обновления определенных функций и выиграть время, чтобы правильно и четко спланировать решение.

К концу февраля мы были в ситуации готовности к развертыванию продуктивной системы. Дальше я буду говорить про продуктив первой и второй версии. Первая версия – та, которую мы хотели делать на OpenShift со всеми вендорскими фишками. Для нее все было протестировано, закуплены лицензии, поддержка, обучение для сотрудников.

И тут случилось то, что случилось.

То, что продуктив еще не был развернут, подтолкнуло нас к решению не оставаться на OpenShift. Мы подумали, что раз ситуация дает нам такой шанс, мы оперативно разработаем план по замене, согласуем со всеми командами разработки и будем готовить новую вторую версию прода уже на «антисанкционных» технологиях. Было принято такое решение, потому что, на наш взгляд, было очень много непонятного, как будут дальше развиваться события с вендорами. В таких условиях лучше рассчитывать на себя и сделать все собственными силами.

ММ: Назови топ-3 риска варианта остаться на OpenShift.

ПЛ: «Поймать» обновление, которое остановит какую-то функцию – это топ-1 риск. Риск номер два – оказаться в ситуации, когда нужна поддержка вендора, и не получить ее. И третий, денежный риск – вложиться в лицензии и не получить их либо вообще не иметь возможности купить и продлить лицензии.

ММ: Звучит очень здраво.

Мы провели опрос среди участников митапа. Результаты такие: 40% участников используют open source Kubernetes, по 15% – Tanzu и OpenShift. Всего 3% используют Kubernetes в облаках и 28% не используют ничего. Что ты думаешь про 3% в облаках?

ПЛ: Мне кажется, этого сейчас должно становиться больше. В условиях, когда OpenShift недоступен и нет возможности быстро набрать свою команду экспертов, которые «приготовят» ванильный Kubernetes, все пойдут в облака. Для меня это было бы логичным развитием событий.

ММ: Давай поговорим про вариант Vanilla Kubernetes. Сценарий «слепить» что-то самостоятельно под себя имеет как плюсы, так и минусы. Основной плюс этого сценария – возможность собрать кастомную платформу, которая сможет удовлетворить все ваши задачи. Настроить мониторинг, логирование, сервисы безопасности, адаптировать под себя Active Directory, развернуть CI, политики безопасности и т.д.

Это здорово, но поддержка будет только от комьюнити. Представим, что мы разворачиваем на такой платформе тяжелый продуктив. Open source компоненты могут вызвать реальные проблемы, и, если у вас нет компетенций, чтобы заглянуть в их код, это станет большой проблемой для решения.

Вопрос номер один: «Брать эту ответственность на себя или не брать?». Вопрос номер два: «Компетенции какого уровня и какое количество людей с этими компетенциями должны быть в команде, чтобы мы смогли сделать адаптированную платформу, удобную в использовании?». Я вижу такие два вызова и тот плюс, что можно сделать все максимально под себя и не тратиться на коммерческое ПО.

Что ты думаешь?

ПЛ: Расскажу про наш опыт. Я считаю, что и OpenShift —решение, которое имеет плюсы и минусы. Плюсы в том, что оно протестировано, имеет вендорскую поддержку, мощное комьюнити, обучение и т.д. Но минусы в том, что в одну корзину собрали все, в том числе то, что вы не будете использовать, а это будет есть ресурсы.

Давай разложим по технологиям: что есть в OpenShift, что мы там использовали, что нет, и какие замены нашли в Vanilla Kubernetes.

Security police и post security police – политики безопасности, которые в Kubernetes тоже есть, настроить несложно.

Встроенный мониторинг OpenShift – красивый и приятный, но если у вас средняя или большая инфраструктура, то скорее всего есть еще внешний мониторинг, который отдает метрики на уровне приложения. С небольшими доработками можно вынести весь мониторинг, как инфраструктурный, так и программный (контейнерный), и использовать, например, Prometheus. Мы используем для мониторинга связку Prometheus, Grafana, ELK для логов. Планируем внедрять Sentry для сквозного мониторинга.

CSI – хранилище персистентных данных в OpenShift. Мы обошли этот момент, ничего такого не поднимали, используем managed service облачного провайдера. Если делать on-premise, то придется развертывать, например, Ceph. Не знаю идеального рецепта, мы сами пока не решили, что будем делать. Есть желание либо отдать это в какой-то аппаратный storage, либо сделать свой Ceph. Пока не в планах на этот год.

Авторизация в OpenShift из коробки, а в Kubernetes ставятся операторы, можно нарастить встроенными инструментами. Цена вопроса – тоже не rocket science, достаточно компетенций специалиста среднего уровня, и в интернете очень много документации, как сделать авторизацию.

Operator Hub в OpenShift – как «магазин приложений», встроенная функция, с помощью которой можно расширять OpenShift. Очень крутая штука. Ее большой плюс в том, что уже все протестировано и одобрено вендором, проблем либо не будет, либо вам помогут. В ванильном Kubernetes решается поднятием еще одного контура, выделением времени на предварительное тестирование перед выводом в продуктив, то есть потребуется немного дополнительных ресурсов. Все решаемо. Как мне кажется, ключевые функции контейнеризации меняются не часто – обычно с очередной архитектурной волной, раз в полгода-год.

ММ: Вы пользовались этим маркетплейсом OpenShift? Я с разными клиентами разговариваю, и кто-то считает его бесполезным, а кто-то реально использует. Как у вас?

ПЛ: Мы скорее нет, чем да. Была пара фишек, которые оттуда взяли. Но даже при наличии OpenShift у нас есть эшелон стендов – прод, пре-прод, различные стенды разработки и тестирования. Мы имеем возможность функцию из Operator Hub посмотреть предварительно не в продуктиве. Такая эшелонированная проверка будет у любого разумного человека, который организует инфраструктуру.

Про планирование ресурсов: OpenShift потребляет ресурсов в 2-3 раза больше по сравнению с вашим кластером Kubernetes. Надо отдавать себе отчет, что все функции, которые идут по умолчанию, съедают ресурсы.

Управление конфигурациями machine.config есть в коробке Оpenshift, а для Kubernetes решается через Ansible. Не так удобно, но я уверен, что при подходе IaaC не иметь компетенций по Ansible или не купить эту компетенцию у кого-то еще – значит не уметь автоматизировать инфраструктуру.

Это все ключевые моменты.

В нашей команде на старте было четыре человека разного уровня, и мы переделали прод примерно за четыре месяца, плюс два месяца заняли финальные тестирования, интеграция и вывод сервисов в продуктив, все работы – с февраля по август.

ММ: Здорово, что сразу привел сравнение: функции, которые были в OpenShift, и как это можно реализовать в Kubernetes. Глобальный посыл в том, что все функции в том или ином виде можно воспроизвести в open source варианте. Если есть опыт, компетенции и понимание, какую задачу решаем, инструмент точно найдется.

Давай обсудим сценарий перехода на российские аналоги. Сейчас самое популярное решение – Deckhouse компании Флант, платформа их собственной разработки, под капотом Kubernetes, входит в Реестр российского ПО. Многим клиентам важно, чтобы платформа контейнеризации была в Реестре.

Я вижу сейчас окно возможностей для тех, кто хочет захватить этот рынок, предоставив качественную платформу. Твое мнение?

ПЛ: Очень круто, что на рынке развивается такой продукт. Мы на него тоже смотрим. Поясню, почему мы его не внедряли. Во-первых, решение нужно было принимать быстро. У нас был спланирован вариант с учетом того, что на OpenShift уже потеряли часть бюджета на развитие. Оставались риски, что мы не сманеврируем и не сможем закупить Deckhouse. Vanilla Kubernetes рассчитывался по ФОТ, его было проще планировать.

Кроме того, наша команда пока не до конца знакома с функциональностью этой платформы. Пришли к выводу, что и без того слишком много информации, которую нужно проверить, чтобы изучать еще и эту платформу и выпускать на ней продуктив. Раз уж мы решили делать все сами, то полумер быть не может.

Но обязательно проанализируем Deckhouse с точки зрения следующих вариантов развития.

ММ: Давай обсудим последний, облачный сценарий. У твоей команды большой опыт использования публичных облаков, интеграции публичного и частного. Есть сценарий получить Kubernetes как сервис облачного провайдера. Это удобно, когда мы говорим про стандартизированные среды, которые используются под разработку и тестирование, и сокращает time to market. Но есть и обратная сторона, когда ты оказываешься привязан к функциональности конкретных облаков. Расскажи подробнее про ваш опыт.

ПЛ: Да, облака – очень удобный вариант с точки зрения планирования ресурсов, их можно получить по клику. PaaS снижают требования к квалификации команды поддержки, не нужно самостоятельно разворачивать кластеры и т.д.

Какие минусы? Первый минус любой облачной платформы – она развивается со своим road map. Есть функции, которые вам нужны, но их там не будет. Либо наоборот, вы пользовались какой-то функцией, а ее потом убрали, потому что она мало кому была нужна. Мы часто сталкивались с такими ограничениями, после которых свое частное облако становится очень родным, потому что там ты можешь делать все что угодно.

Например, в DBaaS мы столкнулись с тем, что не можем выполнить требование службы безопасности ИТ – зашифровать и выгрузить бэкап. Виртуальные машины также проблематично выгрузить и где-то еще развернуть. Облачная платформа всегда хочет, чтобы ты с ней остался надолго.

Также мы столкнулись с ограничениями сетевых технологий – например, всего семь IP-адресов на виртуальном интерфейсе виртуальной машины. А нам нужно было сделать сложную сетевую конфигурацию с различными движениями трафиков, с зонным сегментированием.

Когда такие мелочи накапливаются, хочется выйти на следующий уровень и реализовать подобные сложные вещи в своем частном облаке.

ММ: Но при этом вы в облаках остаетесь. Расскажи почему.

ПЛ: Одна из основных причин – масштабирование контуров. Мы движемся к схеме, когда наши контуры будут разворачиваться on demand. Если разработчику нужны дополнительные ресурсы, он нажимает волшебную кнопку, по которой ему развертывается стандартный типовой контур, и может что-то выкатить и проверить, не отвлекая DevOps-специалистов.

Ключевым условием для такого удобства является поддержка облачным провайдером автоматизации Terraform. В противном случае придется тратить много усилий на изменение конфигураций ваших контуров.

Большое облако – это всегда распределенная инфраструктура, резервирование, это инструменты внешней балансировки и Anti-DDoS. Это сильный фронт, который может спасти фронтальную часть вашего сервиса от лишних нагрузок. В рамках одного ЦОД это сделать сложнее.

Кроме того, PaaS-решения экономят деньги по сравнению с тем, если бы вы собирали такую же конфигурацию на своих ресурсах.

ММ: Мы обсудили общую проблематику, предлагаю теперь перейти к вашему опыту. Давай еще раз коротко напомним о ходе событий и перейдем к внедрению того решения, на котором вы остановились.

ПЛ: Встречаем новую реальность – это февраль 2022 года. Весь прошлый год мы планировали, закупали железо, строили ЦОД, собрали хорошее гиперконвергентное решение на базе Nutanix –умная платформа, которая нативно может отдавать хранилище типа S3, имеет свой оркестратор. Цели – получить надежное high end-решение с возможностью оперативной замены, снизить стоимость владения. Также потратили большие средства на Next Generation Firewall известной фирмы с функциями расшифровки трафика, умных проверок URL и многими другими, которые могли закрыть проблемы безопасности нашей инфраструктуры.

Все эти вещи либо отключились, либо превратились в тыкву, и мы остались с минимальным набором функций из того, что купили и на базе чего хотели строить частное облако. В первый момент не было понимания, что будет дальше. И мы решили, что будем действовать самостоятельно, сфокусировались на минимальной проверке концепции, выбрали исключительно open source решения, например, RedHat Enterprise Linux заменили на Oracle Linux, вместо OpenShift – Vanilla Kubernetes.

Поняли, что в этой новой реальности не можем строить собственное облако, вернулись к своему облачному провайдеру, от которого планировали по максимуму уходить в этом году, и развернули там новую продуктивную среду на «антисанкционных» технологиях.

Основную концепцию мы назвали «платформа-кибитка». Подход состоит в том, чтобы сделать нашу платформу максимально независимой от какого-либо облака, либо частного, либо публичного. Рецепт успеха: должен быть провайдер Terraform, все развертывание автоматизировано с точки зрения Infrustructure as a Code. А идеальная формула успеха, которую мы еще не реализовали, но реализуем обязательно, это автономная IP-сеть. В этом случае вы сможете быстро развернуться у любого провайдера с минимальными доработками.

Такая концепция обеспечивает комфортное поведение и прогнозируемые действия в любых ситуациях, например, когда облачный провайдер резко повысил цену или руководство вдруг решает перестроить модель бизнеса и больше не закупать железо, перейти от CAPEX к OPEX.

ММ: Напомню, что на это внедрение ушло 4 месяца силами 4 инженеров. Я так понимаю, не junior-инженеров?

ПЛ: Middle/senior – второй/третий уровень. Дай нам скидку, мы находились в состоянии аффекта, не останавливали текущий продуктив и поставки. Схема поставок изменилась. В отсутствие целевого прода, все команды почти полгода собирали большой-большой релиз. Получился такой микросервисный монолит. Это был серьезный маневр, требовавший максимум усилий от всех команд. В итоге мы его выкатили нормально. Я не рекомендую так делать, но это был вынужденный подход, потому что, если бы пришлось одновременно выпускать новые релизы и «допиливать» старый продуктив, эти 4 месяца превратились бы в год.

По нашему опыту, время на уход с OpenShift можно сократить, потому что в него заложены проверки разных концепций, анализ, что выбрать. Скорее всего, выбор за вас кто-то уже сделал, просто надо поискать релевантный опыт.

ММ: В продолжение расскажу известный мне кейс крупного банка. Там очень много сервисов было завязано на OpenShift, развернуто десятки кластеров. Они тоже выбрали путь перехода к open source, к развитию собственной платформы, сами делают автоматизацию для управления разными кластерами. Большой проект еще идет, займет около 6 месяцев, участвуют 24 инженера. На расширение команды и для того, чтобы все сделать в нужные сроки, уже потрачено больше ста миллионов рублей.

Частый аргумент в пользу перехода с OpenShift – экономия на лицензиях. Похоже, что это не всегда так, потому что приходится добирать людей с нужными компетенциями, чтобы все заработало и потом поддерживалось.

ПЛ: Если у вас нет внутри нормальной команды, на которую можно положиться, и нет проверенного вендора, который может реализовать такой проект, я бы не рекомендовал делать Kubernetes своими руками. Лучше обратиться к облачному провайдеру, купить Kubernetes as a Service и добиваться решения проблем от поддержки, если что-то пойдет не так. В противном случае можно потратить много денег, а рабочего финального результата не получить.

ММ: Но не всем можно в облака по разным причинам.

ПЛ: Обычно те, кому нельзя, сильно зарегулированы, то есть у них, скорее всего, есть свои ресурсы по защите ИТ, своя инфраструктура и поддержка. Значит, их рецепт – «вариться» внутри.

ПЛ: Ключевые моменты замены OpenShift – это автоматизация развертывания; логирование и мониторинг (скорее всего, у вас есть свой внешний мониторинг, потому что если нет и вы хотите работать с микросервисами, значит, вы что-то делаете не так); балансировка, масштабирование, инфраструктурные компоненты. Это вещи, которые можно на первом этапе делать руками, а потом аккуратно автоматизировать. И всегда нужно проверять – придется потратить время и привлечь команду, которая будет проверять ваш сервис. Сейчас говорю от лица технарей, предоставляющих внутреннюю платформу для команд разработки.

Ошибки и трудности мы частично затронули. Санкционные технологии – непонятно, что будет завтра. Сейчас ощущение паники ушло, но в тот момент, когда мы принимали решение, нервозности было много. Проверка требуемой функциональности: не верьте вендорам, обязательно проверьте сами. Очень сложно быстро все согласовывать со всеми направлениями (архитектура, защита ИТ, разработка), чтобы они поняли, что мы делаем, как меняем. И, самое главное, выпустить к этому минимальную документацию. Если делать без описания, мы потом просто забудем, что сделали.

Главный совет – не бояться. Если кто-то испугался и замер, то время его не пощадит. До него докатятся блокировки и санкции. Выход из ситуации нужно искать здесь и сейчас. Не обязательно бежать сломя голову, но перестать бояться, определить вектор своего развития и двигаться туда.

По нашему опыту, все технологии, которые мы сегодня обсудили, можно заменить. Для этого нужно либо иметь команду, на которую можно положиться (но формировать ее сложно и долго, мы на это потратили около двух лет), либо выбрать действительно хорошего вендора и тщательно с ним обсудить, что вы хотите. Если этого нет, браться своими силами за проект замены Kubernetes я не рекомендую. Придут какие-нибудь DevOps-сказочники и потратят много ваших денег.

И всегда продумывайте запасные варианты – это универсальный совет. Когда мы сейчас делаем какие-либо замены, всегда имеем под рукой план B. Могут быть ошибки согласования, например, со стороны архитектуры, со стороны вендора. Желательно себе соломку подстилать.

ПЛ: Сейчас мы чувствуем себя очень неплохо. У нас есть связка из публичного облака и двух стоек частного облака в ЦОД (то, что осталось от гиперконвергенции). Для частного облака будут проверяться концепции, в каком виде его оставить: заменить гипервизор на альтернативный либо реализовать как bare metal. Кроме того, есть одна стойка legacy. Программа существует давно, и часть функций остаются в виде монолита. Их мы будем постепенно превращать в микросервисы.

Также у нас есть интеграция с банками, платежными шлюзами, партнерами. Для пользователей наш продукт выглядит как маркетплейс. У вас есть мобильное приложение, в котором вы выбираете товар, например, холодильник, оплачиваете бонусами либо доплачиваете карточкой, вам оформляют доставку и привозят домой. Поэтому все сопутствующие интеграции – платежные, каталожные, партнерские – присутствуют.

У нас типовой микросервисный стек, без особенностей. В этой таблице я также показал, что еще используется Zabbix для мониторинга, преимущественно железа. Для контейнеров используем не Docker, а Podman, который, кстати, тоже имеет особенности работы.

Сейчас, в середине августа, уже развернута вторая, пост-санкционная версия продуктива. Проработан план развития на конец текущего года и на следующий, который включает в себя замену на аналоги тех функций, которых нам не хватало. Это продукты защиты ИТ, связанные с сегментацией сети, файерволлы, фильтраторы трафика и т.д. Также продумываем, как будем использовать железо в текущих реалиях.

Будем внедрять автоматизацию для рационального распределения и экономии ресурсов. Есть два подхода. Можно купить у облачного провайдера несколько кластеров в формате Managed Kubernetes и, фактически, заплатить за лишние ресурсы инфраструктуры Kubernetes. А можно создать один кластер своего Kubernetes и сделать несколько контуров. Чем больше контуров, тем выгоднее собрать отдельный кластер Kubernetes. Каждое решение надо взвешивать с точки зрения вашей специфики. Мы сейчас хотим реализовать второй вариант, чтобы экономить на собственном кластере. Провели калькуляцию и приняли такое решение.

ММ: Я вполне осознаю, каких интеллектуальных усилий это потребовало. Мы проводим такие миграции для наших клиентов, помогаем определить стратегию развития, понять, что лучше подойдет: оpen source Kubernetes, облачный PaaS, Deckhouse или что-то еще. Иcходя из нашего опыта я понимаю, какой огромный пласт работы вы подняли. Большие молодцы! 

Вопрос. Меняли ли вы операционную систему?

ПЛ: Нет, не меняли. Хотим сначала посмотреть, как это получится у нашего партнера, крупного банка, потому что прекрасно понимаем, что это чревато большими сложностями.

Вопрос. Почему Ansible?

ПЛ: Это стандарт де факто, практически любой DevOps-специалист знает эту технологию и ее эффективно использует.

Вопрос. О каком количестве и размере кластеров идет речь?

ПЛ: Сейчас в продуктивном кластере развернуто около 40-50 микросервисов из 100 целевых, то есть примерно половина целевой схемы. Целевой схемой я называю то, что мы получим с учетом поглощения всего legacy. Размер кластера для 40 сервисов – это 128 процессоров, 512 ГБ памяти, 5 ТБ быстрого и 5 ТБ медленного хранилища. В целевой схеме этот кластер вырастет в 2-3 раза. Таких кластеров несколько, есть кластеры под разработку, интеграционное тестирование и т.д. Общий объем ресурсов надо увеличить примерно в 6 раз.

Вопрос. Есть ли планы по расширению команды?

ПЛ: На текущий год мы упакованы. Команда по направлению DevOps состоит из двух троек. Одна занимается непосредственно DevOps-направлением, то есть поддержкой разработки. Вторая сфокусирована на SRE-направлении, то есть на мониторинге, логировании, повышении производительности, расшивке всех узких мест. Так как мы уже «взлетели», надо шлифовать самые нервные проблемные места. Коллеги занимаются оптимизацией производительности.

Вопрос. Интересен опыт поддержки: круглосуточные сменные графики или на телефоне?

ПЛ: У нас поддержка эшелонированная и многоуровневая. Короткий ответ: DevOps-ы на телефоне. Но у нас структура продукта такая, что, помимо системы мониторинга, проблемы отлавливаются еще через клиентский колл-центр. Наша поддержка уровня приложения работает сейчас не круглосуточно, но планируем выходить на 24/7.

Вопрос. Есть ли в организации служба защиты ИТ-инфраструктуры, которая накладывает ограничения на инфраструктуру Kubernetes?

ПЛ: Да, есть. Это наша боль и одновременно стимул к развитию. Мы являемся трансляторами с языка защиты ИТ на язык лучших практик инфраструктуры. Например, требование «сегментация сети» означает, что из тестовой среды не должно быть доступа в продуктив. Мы должны это обеспечить на уровне Kubernetes, firеwall, namespace. Нам редко предъявляют конкретные требования, но перевести их на человеческий язык, разложить по технологиям и реализовать – это важные и нужные задачи. И мы все понимаем цель этих задач – сделать стабильную надежную платформу, чтобы ее не атаковали хакеры.

Вопрос. Разработка, тестирование и продуктив размещены на разных кластерах?