Недавно мы провели вебинар совместно с коллегами из Yandex Cloud и «Антиплагиата».
Нурсултан Калниязов, архитектор Yandex Cloud, рассказал о сертификации Deckhouse Kubernetes Platform (DKP) в Yandex Cloud и преимуществах интеграций; Константин Аксёнов, руководитель разработки Deckhouse, — о разных сценариях использования DKP в облаках; и Андрей Ивахненко, руководитель отдела внедрения и эксплуатации, — об опыте внедрения multicloud-подхода командой «Антиплагиата».
Делимся с вами текстовой версией вебинара.
Зачем нужна сертификация Deckhouse Kubernetes Platform в Yandex Cloud
Нурсултан Калниязов, архитектор Yandex Cloud
Сертификация подтверждает совместимость DKP с Yandex Cloud, гарантирует работоспособность платформы в облаке и, соответственно, качество продукта. Yandex Cloud и Deckhouse не только проверили совместимость, но и разработали дополнительные интеграции с различными облачными сервисами, где особое внимание уделили безопасности.
Преимущества использования Deckhouse Kubernetes Platform в Yandex Cloud
DKP предлагает унифицированный подход к разворачиванию Kubernetes-платформы, понятную модульную структуру и управление жизненным циклом кластеров. Защищённость и работоспособность Kubernetes-кластеров определяется в том числе и механизмом групп безопасности — Security Groups.
Интеграция групп безопасности
При создании облачных сетей создаётся группа безопасности по умолчанию с набором правил как по входящему трафику, так и по исходящему трафику. Правила в группе определяются наборами протоколов, диапазонами портов, типами источников.
Интеграция с сервисом Yandex Lockbox
В маркетплейсе Yandex Cloud для Kubernetes есть инструмент External Secrets Operator с поддержкой Lockbox. Это оператор Kubernetes. Сущность SecretStore даёт возможность создавать хранилище секретов. Объект ExternalSecret указывает на секрет в хранилище. То есть фактически обеспечивается синхронизация секрета из Lockbox и секрета в Kubernetes.
Если посмотреть на правую часть рисунка 👆, то есть на спецификацию в разделе remoteRef → key, то мы увидим <ИДЕНТИФИКАТОР_СЕКРЕТА>. Здесь под секретом имеется в виду секрет в Lockbox. Секреты в Lockbox имеют возможность версионирования. Эта поддержка есть. Синхронизация будет происходить в то, что есть в спеке, а именно в target → name. Таким образом, значение хранится в Kubernetes-секрете с именем k8s-secret. Сценарий, который мы реализуем и в котором позволяем DKP интегрироваться с Yandex Cloud, заключается в синхронизации секретов из Lockbox в Kubernetes-кластеры.
Интеграция с Prometheus
В этой интеграции доступна функциональность записи и чтения метрик. Тут речь о Remote API, об интеграции с собственными инсталляциями Prometheus. Также есть функциональность по чтению метрик через Grafana. Сервис Prometheus находится в General Availability, он публично доступен пользователям. Сценарии, которые мы можем предоставить совместно с Deckhouse: с помощью Prometheus мы можем «сливать» метрики из разных кластеров, организовывать централизованное хранилище метрик*. То есть мы решаем задачу, что нам делать с метриками. И ответ на это — использовать Prometheus (Yandex Managed Service for Prometheus).
* Централизованное хранилище метрик позволяет работать с метриками через единую точку, что упрощает взаимодействие с метриками в случае большого количества кластеров Kubernetes.
Сценарии совместного использования Deckhouse Kubernetes Platform и Yandex Cloud
Константин Аксёнов, руководитель разработки Deckhouse
Команда DORA (DevOps Research and Assessment), подразделение Google Cloud, выпустила в 2023 году новое исследование Accelerate State of DevOps Report. Отчёт направлен на то, чтобы усилить эффект от использования практик DevOps в компании. В нём целый раздел посвящён термину гибкая инфраструктура.
Гибкая инфраструктура (flexible infrastructure) — это концепция, описывающая способность системы или организации быстро и эффективно адаптироваться к изменяющимся условиям, требованиям или нагрузкам. Гибкая инфраструктура обычно означает, что система способна масштабироваться, изменяться или переконфигурироваться без значительных затрат времени и ресурсов.
И главное — всё это должно происходить в автоматическом режиме без значительных затрат времени и ресурсов, когда появляются дополнительные требования к системе или нагрузки.
Использование облачных вычислений — основа гибкой инфраструктуры. Приватные и публичные облака существенно повышают возможность динамически изменять конфигурацию инфраструктуры. Но при этом важное замечание в отчёте: сам факт использования облаков не приводит автоматически к успеху.
Что это значит? Недостаточно сказать: «Всё, у меня теперь облако, раньше я запускал виртуальные машины на своём железе, а теперь я те же самые виртуалки взял, мышкой накликал в облаке и автоматически повысил все свои метрики. У меня теперь релизы будут быстрее и восстановление во время релиза тоже будет быстрее». Важно понимать, как компания использует облако и как это влияет на результаты: на производительность компании, автоматизацию и возможность быстро реагировать на изменения.
Гибкая инфраструктура влияет на производительность команды и компании, ускорение доставки ПО и упрощение эксплуатации. Происходит это за счёт использования облачных вычислений. Немаловажный фактор в отчёте — использование облачных вычислений и гибкой инфраструктуры положительно влияют на благополучие сотрудников. Естественно, мы хотим, чтобы сотрудникам в компании работалось комфортно и чтобы работа была им интересна. Когда инженер работает с разными облаками и технологиями, он повышает свою компетентность. Это важно для айтишников — чувствовать, что они растут как профессионалы и будут востребованы на рынке труда в дальнейшем. Этот фактор также учитывается в отчёте — сотрудники получают больше удовлетворения от работы, меньше выгорают и эффективнее работают.
В исследовании приводятся как приватные и публичные облака, так и гибридные и мультиоблака (multicloud). Разберём последние два сценария на примерах.
Гибридные облака
У клиента Deckhouse — компании Mindbox — гибридная инфраструктура. Mindbox — платформа автоматизации маркетинга, которая помогает собирать и обрабатывать данные о клиентах, автоматизировать коммуникации, управлять ими. Это сервис, с помощью которого бизнес, клиенты, заказчики хотят донести свои маркетинговые кампании до конечных пользователей. Рассмотрим простую задачу, которая возникает у Mindbox.
Через сервис заказчик хочет отправить почтовую рассылку на Х миллионов адресов. У нас есть Kubernetes-кластер под управлением DKP, который работает как поверх собственного дата-центра, так и в интеграции с Yandex Cloud. В момент поступления задачи на рассылку работают 3 реплики приложения. Система понимает, что надо масштабироваться.
Появилась метрика, что в очереди на рассылку висит миллион задач. В автоматическом режиме настроен автоскейлер, который горизонтально увеличивает количество реплик. И автоматически появилось дополнительное количество реплик. При этом мы видим, что на worker-узлах помещаются максимум 2 реплики. То есть на одном из worker-узлов были свободные ресурсы, запустилась ещё одна реплика. Всё, больше у нас приложениям негде запускаться. Мы должны эти приложения где-то в другом месте разместить, чтобы эффективно и быстро обработать задание. Возникает потребность — надо добавить новые worker-узлы.
И есть автоматический скейлинг узлов через автоматический заказ узлов в Yandex Cloud. Соответственно, происходит процесс автоматического заказа узлов в облаке и добавления их в кластер. Приложения запускаются на новых узлах автоматически — мы видим, что они все в рабочем состоянии.
И учитывая большое количество реплик приложения, рассылка обрабатывается быстрее.
Что происходит дальше? Когда все задания обработаны, так же автоматически происходит уменьшение количества реплик приложения, потому что та метрика, по которой мы масштабировались, показывает нам, что такое количество запущенных приложений уже не требуется.
И как только система понимает, что не требуется столько реплик держать, worker-узлы освобождаются, и их можно удалить.
Без участия инженера worker-узлы в Yandex Cloud удалены. Соответственно, мы не платим за использование ресурсов. Получается, что без дополнительного вовлечения инженеров, мы получили быстро обработанное задание.
Плюсы гибридной инфраструктуры
В первую очередь это экономия ресурсов. Нам не надо в собственном дата-центре держать избыточное количество собственных мощностей с прицелом на то, что у нас может возникнуть пиковая нагрузка и нам нужно будет обработать большие наборы заданий или принять большой объём трафика. Мы экономим ресурсы и тем самым экономим деньги, не держим у себя лишние мощности внутри.
При этом мы получаем удовлетворённых клиентов за счёт того, что можем динамично реагировать на изменения и быстро обрабатывать пиковые нагрузки.
Гибкая инфраструктура положительно влияет на сотрудников компании, потому что команда эксплуатации не задействована. Если раньше пришлось бы срочно выискивать дополнительные мощности, добавлять новые железки в кластеры и дополнительно что-то восстанавливать, чтобы быстрее обработать задания, то здесь все операции автоматизированы, а DevOps-инженер занимается своими задачами. Он не вовлечён в стрессовые ситуации, когда надо срочно включиться в работу.
Multicloud-инфраструктура
Исследование DORA подчёркивает, что использование одного публичного облака увеличивает показатели гибкости инфраструктуры больше, чем одновременное использование нескольких облаков.
Если инженер работает с одним облаком, с одной облачной платформой, то он привыкает к интерфейсу, у него настроены автоматизации, ему не надо погружаться в документацию, он знает, как работать с этой платформой. Когда рядом возникает ещё один интерфейс взаимодействия, это автоматически увеличивает когнитивную нагрузку, с которой требуется справляться инженеру. И кажется, что multicloud-инфраструктура вносит только сложности.
Далее расскажем, как упростить внедрение multicloud-подхода, действительно ли он такой сложный или всё-таки есть плюсы и как использовать его во благо своей компании.
Как «Антиплагиат» использует облака и собственное оборудование с Kubernetes-кластером под управлением Deckhouse Kubernetes Platform
Андрей Ивахненко, руководитель отдела внедрения и эксплуатации «Антиплагиата»
«Антиплагиат» — это специализированный поисковик, предназначенный для обнаружения заимствований. В отличие от обычного поисковика вы загружаете не несколько слов, а документ с текстом. «Антиплагиат» ищет, где ещё встречаются те или иные фрагменты текста. В качестве результата вам выдаётся отчёт, в котором подсвечиваются найденные фрагменты и даются ссылки, где ещё это было найдено. Ищем мы не только в интернете, но и по различным закрытым базам, таким как коллекция диссертаций РГБ, IEEE, eLibrary. Также мы развиваем неклассический поиск — поиск по переводным заимствованиям, недавно добавили выявление сгенерированных искусственным интеллектом текстов и поиск заимствованных изображений с учетом изменений.
На пике число слов, приходящих на проверку в виде текстовых документов, сравнимо по порядку с количеством слов, которые попадают, например, в запросы поисковой машине Яндекса.
Чтобы понимать, какой у нас примерно объём Kubernetes: суммарно наши Kubernetes-кластеры сейчас, в марте 2024 года, — это 3,5 тысячи подов, 1800 ядер и более 5 терабайт памяти. В летнюю сессию ожидается 4–8-кратный рост как минимум.
На текущий момент мы используем Kubernetes под Deckhouse-платформой, Jenkins. Всё ещё есть немного монолита.
Наш софт разрабатывается архитектурно таким образом, чтобы он был распределённым по нагрузке. Мы толерантны к выходу из строя одного дата-центра целиком, одной машины с быстрым диском, одного быстрого диска. Нам очень важно иметь максимальную производительность SSD. То есть строго SSD в один слой, без RAID’ов, Ceph, LINSTOR и всего остального. Соответственно, наша бизнес-логика умеет балансировать нагрузку, и наши сервисы есть в разных дата-центрах.
Из этого мы делаем следующий шаг — наши продуктовые кластеры построены на спотовых и прерываемых инстансах. Почему? Kubernetes в принципе рассчитан на то, чтобы в случае отзыва какого-то узла заменять его, перераспределять нагрузку, поднимать заново упавшие приложения. Мы решили — почему бы и нет. Отзыв узлов в облаках доставляет проблемы, но они эпизодические. Если нет чего-то серьёзного, какого-то глобального падения оборудования у платформы, в целом всё нормально. Но при этом мы достигаем экономии в 60% на вычислительных ресурсах.
У нас образы с «толстыми» моделями. Поиск картинок, поиск текста, сгенерированного искусственным интеллектом, переводные заимствования — всё это требует достаточно больших моделей машинного обучения, языковых моделей. Поэтому нам нужно уметь работать с большими объёмами данных, которые нужно подгружать из S3, как-то располагать на PVC, на дисках. Yandex и Amazon всё-таки по-разному устроены, и характеристики в дисках тоже различные. В Yandex Cloud мы, к сожалению, не смогли настроить работу с SSD с прямым доступом. В Amazon есть инстансы типа i3, i4, и это крутые штуки. В Yandex Cloud отсутствуют диски, похожие по характеристикам на gp3 в Amazon. Есть другие, но у них тоже имеются свои ограничения, в частности объём кратен 93 ГБ.
Разные размеры инстансов: Amazon позволяет использовать спотовые инстансы в полтора, два, три раза больше, чем Яндекс. И в целом в Amazon есть железо посвежее, но за это нужно расплачиваться тем, он дороже и оплата в долларах.
Как мы пришли к Deckhouse Kubernetes Platform
Началось всё с того, что команда инженеров SRE сказала: «У нас количество сервисов растёт, а давайте мы оркестрацию сделаем». Внутри команды экспертиза отсутствовала. Kubernetes — это Open Source: очень много туториалов и так далее. Выяснилось, что поставить Kubernetes — это даже не 10% дела. Мы столкнулись с тем, что у нас были тысячи развилок: какие компоненты выбрать, какими средствами, что и как делать. Плюс накладывалось то, что поддержку продакшена никто не отменял. Тут же и сессия навалилась — лето пришло, нагрузка возросла. Всё это было медленно. За год мы Kubernetes-кластер, конечно, развернули. Он у нас как-то работал. Там даже было одно или два приложения. Но в целом это закончилось, можно сказать, неудачей. Через год мы приняли решение, что это нам не подходит, и дело свернули.
Следующая попытка — «Давайте мы будем использовать managed Kubernetes от различных провайдеров». На тот момент мы использовали несколько облаков. И сейчас у нас есть аккаунты, которыми мы активно пользуемся. По-моему, пятью или шестью облачными провайдерами с той или иной степенью интенсивности. Для managed Kubernetes-кластеров мы столкнулись с такими проблемами, как разные версии дистрибутивов, разный жизненный цикл, версии Kubernetes появляются в разное время. Дистрибутивы тоже разные, разный мониторинг, разный алертинг, аутентификация — и всё это нужно сводить вместе. Функционал деплоя приложений был в целом похожим, но имелись сотни мелочей, в которых была разница. И уже на этапе деплоя, на этапе развёртывания мы поняли, что это тоже, в общем-то, фейл и, скорее всего, мы закончим примерно так же, как и при первой попытке.
Потом заинтересовались Deckhouse Kubernetes Platform и решили попробовать.
Выводы из опыта использования Deckhouse Kubernetes Platform
Kubernetes — внезапно — это дорого и даже очень дорого. Если вы самостоятельно хотите поддерживать кластер Kubernetes, у вас должна быть профессиональная команда, которая занимается только этим и имеет обширную практику, обладает нужным опытом. Если вы собираетесь всё это надёжно поддерживать, у вас должно быть много кластеров и люди, человек пять минимум — с учётом отпусков, больничных, передачи опыта.
Эти расходы не покрываются даже оптимизациями и использованием спотовых инстансов. Это дорого.
Мультиоблачные кластеры — это удобно для высоконагруженных систем. Особенно с использованием Deckhouse, потому что это действительно снижает когнитивную нагрузку на инженеров. Всё везде одинаково, единый код, внесение изменений не требует существенных усилий.
Единообразное управление в разных облаках, резервация функциональности на уровне разных облачных провайдеров: когда одно и то же приложение работает и там, и там. При этом выход из строя или полный развал одного провайдера спокойно переживается. Но, конечно, требуется вкладываться в инфраструктуру резервирования, распределения. Ваш бизнес должен иметь соответствующий размер, чтобы это было для вас оправданным.
Зачем всё это нужно бизнесу, если так дорого и нужно вкладываться?
- В первую очередь это потрясающий time-to-market. Через 15 минут после релиза — время на развёртывание — всё в продакшене, пожалуйста.
- Уменьшение расходов. Мы используем вертикальное и горизонтальное масштабирование. Всё масштабируется, причём не просто по метрикам CPU. Мы пришли к выводу, что эти метрики не очень хороши. Мы используем свои, кастомные метрики, долго к ним шли, и в нашем случае это начинает хорошо работать.
- Мелкие сервисы больше не занимают целых машин, даже очень маленьких, а растворяются на фоне всего Kubernetes-кластера и не засоряют пространство: стандартные worker-узлы сами поднимаются и опускаются.
- «Флант», вендор Deckhouse, позволяет иметь небольшую DevOps-команду, которая сосредоточена на задачах автоматизации бизнеса, то есть ближе к бизнесу, чем к поддержке самого Kubernetes-кластера, — внутренняя автоматизация, помощь командам разработки. При этом она имеет хорошие скилы в Kubernetes, понимает, как всё это работает, и мы «под капот» DKP периодически залезаем.
- Yandex Cloud позволяет экономить на прерываемых инстансах. Не у всех российских облаков это есть — мы с этим столкнулись.
Запись вебинара вы можете посмотреть здесь.