В этой статье мы расскажем о том, как в ОТП автоматизировали развёртку Kubernetes в изолированной среде, обрабатывающей чувствительные данные. Поэтому примеров кода не будет, как и деталей нашего харденинга — это был бы очень длинный и специфичный список. Но на идейном, архитектурном уровне, как мы считаем, этот опыт может быть интересен.

В начале был хаос. Ну, почти

В ОТП около сотни различных команд разработки. Они использовали один из двух подходов:

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

Либо обращались к рекомендациям и инструкциям по развертыванию решения на основе kubespray — их написала наша внутренняя гильдия в методологическом подразделении IT-инструментов.

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

Добавим сюда естественную текучку кадров, и последствия очевидны — чужие инструменты кастомизации, без общих стандартов, хорошо если хоть как-то документированные, неудобны никому, кроме тех, кто их принёс с собой.  Сложно было не то что устранять очевидные аварии, но даже вносить изменения в кластеры. Аналогичные вопросы возникали и у нашей службы ИБ: качественно контролировать разношерстные кластеры непросто.

Частное облако — первый подход к проблеме

Частное облако мы начали внедрять для задач быстрого развертывания виртуальных машин. За основу взяли Red Hat Openstack, как наиболее зрелый продукт на рынке. Всего за полгода мы развернули его в рабочее состояние.

К сожалению, оказалось, что для команд разработки облако не так интересно, как мы ожидали. Да, с облаком удобнее, чем без него, но, опросив сотрудников, мы поняли, что в голом и пустом состоянии оно людей не очень радует — нужны дополнительные сервисы. Разработчики привыкли поднимать нажатием условной кнопки не только сами ВМ, но и, например, Kubernetes как сервис: то, что умеют делать «Яндекс» или Mail.ru. Без настройки продукта, его сетевых доступов, не вникая в порядок установки и не беспокоясь о поддержке — в публичных облаках поддержка централизована. Просто заполнил форму, нажал кнопку, подождал, и вуаля – необходимый кластер в виде услуги получен. Мы решили, что эту конкурентную возможность действительно важно разработать и внедрить.

Удобство понятно, осталось его обеспечить

Тогда мы начали смотреть, какие на рынке есть варианты коммерческих Kubernetes. Нужны были решения с поддержкой от вендоров: администраторам были необходимы оперативная поддержка, хорошая документация и высокие компетенции вендора в целом. А для внедрения ванильных решений требовалось больше специалистов, к затратам на которых мы не были готовы. Мы рассматривали Tanzu, Rancher, Openshift — и российский Deckhouse, у которого в нашей стране альтернатив по функционалу и компетенциям специалистов вендора практически не было и нет.

Зарубежные решения в итоге отклонили из-за цены, и не прогадали, потому что наступил февраль 2022 года с понятными последствиями — можно не сомневаться, что поддержки, важной нам по условиям задачи, мы бы лишились.

Deckhouse оказался вполне подходящим — легкость и гибкость развертывания подкупала. Оставалось решить только вопросы установки системы в изолированной от интернета среде — тут ещё раз подчеркнём, что изнутри банка прямого доступа в интернет нет. Для финтеха это обычное дело, но всё же с такими требованиями мы у «Фланта», вендора Deckhouse, оказались первыми.

Начали с опытно-промышленного подхода — в течение трёх месяцев система работала в продуктиве, но с наименее критичными данным. В это время мы в основном фиксировали ошибки и старались их максимально оперативно исправлять. При этом разворачивались как тестовые проекты, так и новые пилотные продуктивные решения.

Забегая вперед – несмотря на большое количество первоначальных ошибок, решение показало свою востребованность.

Приступаем к главному блюду

То есть, к автоматическому развёртыванию кластеров. Надо было создать инструмент для внутренних клиентов, работающий примерно так: на входе общий интерфейс управления частным облаком и не очень большая форма в этом интерфейсе, а на выходе — полностью готовый кластер с мониторингом, внутренним логированием и аутентификацией через Active Directory именно для команды, которая имеет доступ к проекту в частному облаке.

Без нашего облака этот процесс занимает дни, вплоть до недели — надо создать заявку на виртуальные машины, согласовать её, создать саму машину, открыть сетевые доступы — шесть отдельных шагов. Наше решение сократило эти дни до 30-40 минут. Именно такую скорость обеспечивают публичные облака. Мы воспроизвели это у себя внутри банковской инфраструктуры.

Именно требования ИБ здесь критичны: в публичных облаках очень сложно добиться того, чтобы провайдер заменил свои образы на наши, с подготовленным харденингом и нашей кастомизацией. Отдельно контролировать создание каждой виртуальной машины, обеспечивая её настройки, в публичном облаке тоже не так просто, хотя в теории и возможно.

Практические испытания, или «Нет» ручной работе

К нам начали приходить команды без девопса но с желанием послужить подопытными кроликами. Естественно, мы их принимали — системе была нужна нагрузка, чтобы отловить неочевидные, пропущенные в теории ошибки. Сработало сарафанное радио, и через полгода у нас было уже достаточное количество кластеров с общим стандартом и типом конфигурации. Конфигурация определялась двумя факторами — требованиями ИБ по харденингу и необходимостью подписи PCI DSS. Кастомизация при этом была, но незначительная. Она касалась проектов, ролей доступа внутри них, или, например, дополнительного логирования.

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

Заметим вот что: раньше в каждой команде должен был быть свой девопс, знающий, как инсталлировать и администрировать кластер Kubernetes. В нашем решении девопс уже не нужен, нужен уверенный пользователь Kubernetes — знающий, как он выглядит снаружи, способный развернуть свои приложения. Именно пользователь, не администратор.

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

Подробнее о модулях и настройках

Во внутреннем интерфейсе управления частным облаком мы добавляем настройки, позволяющие членам команды менять конфигурацию кластера. Раньше эти настройки — количество узлов, изменение образа, тарифа — были стандартизированными, менялись вручную или создавались один раз при создании кластера. Если надо было что-то изменить, люди обращались в поддержку. С новым интерфейсом можно будет создать новую или изменить текущую группу узлов автоматически, не беспокоя поддержку. Сейчас этой доработки формально ещё нет, она на подходе, в процессе тестирования, и наши команды её точно скоро получат.

По второму вопросу мы по сути добавили в настройки кластера маркетплейс: там пока что пара опциональных модулей, которые можно подключить, если команде нужен их функционал. Но если будут нужны другие модули, добавить их в маркетплейс большой проблемы не составит.

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

Второй модуль — модуль обновления. Для него мы написали практически уникальное решение — на рынке в таком виде его нет: свой собственный агент, подселяемый в каждый кластер. Агент отслеживает изменения внутри кластера и по мере изменений запрашивает внешние настройки в базе данных. То есть, если человек создаёт новый проект внутри кластера, агент сообщает бэкенду о том, что именно происходит и получает от бэкенда инструкции, как именно докрутить проект до требуемого стандарта. Работает и в обратную сторону — можно изменить на бэкенде настройки определённого кластера, и агент подправит кластер соответствующим образом. Благодаря этому количество кластеров в управлении практически не ограничено — нагрузка на персонал с числом кластеров не растёт.

Если появятся новые запросы, мы будем точно так же смотреть, насколько часто они всплывают и реализовывать для них автоматизацию, над созданием которой работать явно приятнее, чем над рутинными задачами администрирования ☺

О «Фланте» и нашем сотрудничестве

Всё, что описано выше, мы делали в тесном сотрудничестве с вендором. Представители «Фланта» понимали, что мы делаем интересное и довольно универсальное решение, которое может пригодиться не только нам, но и другим организациям — так что все вопросы интеграции мы обсуждали с ними близко и детально. Они помогали даже когда не были обязаны нам помогать — притом, что у нас на тот момент не было расширенной поддержки.

В основном проблемы, которые происходили, были связаны с обновлением: были вопросы по совместимости тех ядер, которые мы используем внутри банка, операционной системы, и компонентов, которые были у Deckhouse.

То есть иногда мы писали интеграцию, но не понимали, как она работает, и обращались к «Фланту» за консультацией.

Параллельно «Флант» написал собственный продукт для централизованного администрирования кластеров. Наш продукт был кастомизирован строго под нас, они же разработали более унифицированное решение и представили его под названием Deckhouse Commander. Подобные решения есть и у других вендоров, у тех же Rancher и Red Hat.

В плане безопасности нам было нужно, чтобы пользователи не меняли конфигурацию кластера в целом. Никаких административных прав дальше своего собственного неймспейса. Это привело к двум проблемам: во-первых, если команда только что создала новый проект, она не получала на него прав. В этом нам как раз помог вышеупомянутый агент — он начал раздавать нужные права, оставляя защищенными системные неймспейсы.

Во-вторых, затруднения с сертификатами безопасности. Новые сертификаты для приложений раньше проходили вручную через нас, но ручных задач, как вы помните, нужно избегать любой ценой. Решили вопрос, внедрив облачный PKI на базе Hashicorp Vault.

Как это выглядит

Вот пара обезличенных скриншотов:

Всё похоже на то, как сделано на Mail.ru. Видны только свои кластеры, их статусы и переход в дополнительные внутренние настройки. Чтобы создать кластеры, достаточно заполнить восемь полей. Для каждого поля есть подсказка о его значении.

В этом интерфейсе пользователю не нужно знать, как инсталлировать Kubernetes в деталях. Достаточно знать, что именно он от Kubernetes хочет и где именно хочет его разместить — доступные варианты открываются в выпадающих меню. Здесь также указан тип хранилища, тип подключенной сети, используемых мастеров.

Как видите, для тестовых сред у нас один мастер-сервер — простота важнее отказоустойчивости. Экономим вычислительные ресурсы, потому что продуктивное решение опирается на три достаточно тяжёлых сервера с Control Plane.

Можно выставить количество воркер-узлов и тип воркеров. Причём, например, если пользователь указал от двух до четырёх воркер-узлов, то сработает горизонтальное масштабирование, и в зависимости от нагрузки, он автоматически получит именно от двух до четырёх узлов. Дальше, когда кластер создан, пользователь может посмотреть или изменить настройки — как выше сказано, мы сейчас открываем их редактирование для пользователей, чтобы им не приходилось обращаться в поддержку.

Потом можно перейти в дополнительные модули своей системы, авторизоваться через Active Directory, получить манифест конфигурации для подключения и управления своим сервером, зайти в Control Plane и через ctr посмотреть на состояние системы и общий статус. Если в статусе что-то красное… то на самом деле беспокоиться не нужно, за этим следим уже мы сами. Сейчас мы готовим централизованный административный мониторинг.

Так нужно знать Kubernetes или нет?

Да. Но только в смысле «Если вы не знаете Linux, вы не сможете работать на Linux». Административный опыт не требуется. В любом случае, у нас есть некоторая база знаний, статей на движке Confluence, которая описывает различные кейсы, ситуации на кластере. Если этого всё ещё недостаточно — банк проводит регулярные обучающие курсы.

Немного о нас самих

Мы сделали это вчетвером — не считая меня, ведь в команде всего трое разработчиков: один эксперт по Kubernetes, и он же сотрудник поддержки. Затем бэкендер, пишущий автоматизацию на Golang, и третий — фронтендер, обеспечивающий UI. При этом на самом деле ребята умеют работать в соседних областях — например разработчик Golang вполне понимает, какие могут требоваться задачи для Kubernetes и принимает их без особой детализации. Без практики и погружения в тему можно долго задумчиво смотреть на API, не особенно продвигаясь в собственно разработке. Аналогично, первый упомянутый эксперт понимает, что можно требовать от Golang.

Но рядом с нами нельзя не упомянуть экспертов «Фланта». Они буквально на своих плечах вынесли большую часть интеграций. Когда у нас что-то не получалось, мы обращались к ним за консультацией и всегда находили решение.

Заключение

Для такой маленькой команды результаты весьма неплохие. Три факта: во-первых, наше решение обсуждается как потенциально общепринятое для всего банка. В конце концов, общий стандарт — это удобно, безопасно и легко отслеживается. Во-вторых, примерно 90% всех новых кластеров, развёрнутых за последние полгода во внутренней инфраструктуре — созданы именно на этом решении. В третьих, требования ИБ соблюдены — в изолированной среде нашего частного облака мы реализовали развёртку Kubernetes с нашими образами, нашим харденингом и нашей же кастомизацией. Успех? Успех!

Надеемся в следующей статье подробнее рассказать о нашем облаке. В конце концов наш PaaS — это всего лишь его часть. Но пока на этом всё — спасибо за внимание!