Представьте, что вас каждый день просят «быстренько развернуть стенд» — с OpenSearch, PPO и десятком доработанных инструментов, «ну чтобы все работало». Сначала вы автоматизируете то, что делали руками. Потом автоматизируете автоматизацию. А потом в какой-то момент понимаете: нужно не писать скрипты, а строить полноценный продукт. Так у нас в Orion soft появился HyperDrive — наш способ развернуть Kubernetes-контуры по-настоящему по кнопке. Сейчас — 200 тысяч объектов развернуты автоматически, на очереди — миллион. И в этой статье я расскажу, как мы это сделали: от боли и хаоса — к параллелизму, GitOps и здравой инженерной оркестрации.

Привет, Хабр! меня зовут Даниил Рахновский, я — ведущий архитектор в Orion soft. В индустрии DevOps — шесть лет, три из которых веду проекты по HighLoad-инфраструктуре. Основную часть этого времени работал на стороне заказчика, потом перешёл на «тёмную сторону» и теперь работаю на стороне вендора. Занимаюсь сложным проектированием в направлении Professional Services.

Orion soft — это вендор. Мы разрабатываем инфраструктурное программное обеспечение, в портфель которого входит целая экосистема продуктов, а именно zVirt, Nova и другие. В Professional Services мы занимаемся аудитом ИТ-процессов, построением программно-определяемых ЦОДов на собственных технологиях. А еще предоставляем экспертизу вендора и поддержку для пользователей, чтобы наши продукты и технологии правильно и эффективно использовались.

В этой статье по мотивам моего доклада для DevOpsConf 2025 расскажу, как мы решали задачи массового деплоя сложных K8s-окружений. Для этого собрали лучшие практики и применили Open-Source-инструменты, а что-то — дописали с командой самостоятельно. Благодаря этой истории вы убедитесь, что DevOps-инструменты при правильном подходе и оркестрации помогают решать задачи по клику на единственную кнопку.

Какие процессы у нас болели

Для начала немного контекста — с чего все началось и какие проблемы нам пришлось решать.

Множество запросов на быстрое развертывание сложных K8s-контуров. В нашей работе мы регулярно сталкиваемся с запросом вроде: «Разверните стенд с огромным количеством наполнений, включая OpenSearch и NeuVector, инструментов от заказчика и демо с точки зрения прикладного программного обеспечения (PPO)». Это отнимало слишком много времени, поэтому мы хотели такие запросы максимально автоматизировать. При этом хотелось обеспечить стандартизированный финальный результат, потому что ручная сборка давала расхождения, а значит — хаос в управлении.  Это была наша следующая боль.

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

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

«Вкалывают люди, а не роботы». Хотелось минимизировать участие человека. В идеале, чтобы он просто делал запрос и получал результат.

Оценив время, которое изо дня в день тратим на рутину, мы поняли: дальше так жить нельзя, нужно решать задачу комплексно.

Проанализировали ситуацию: мы вендор, который много работает с K8s. Нам нужно поддерживать множество сложных инсталляций. При этом не хотим использовать Cluster API, т.к. в нашей контейнерной платформе Nova его нет. Начали искать готовые инструменты, но поняли, что на рынке нет ничего, удовлетворяющего нашим требованиям. Лишь отдельные компоненты, которые вместе могут дать готовый результат. Нам же хотелось получить готовый оркестратор, которого мы не нашли.

Какие задачи хотели решить

«Одно кольцо, чтобы править всеми». Мы хотели использовать один инструмент для управления всем процессом развертывания. Чтобы он закрывал максимум сценариев — от создания инфраструктуры до базовой настройки кластера. Для этого мы заранее определили функциональные границы и зафиксировали список возможностей:

• Создание виртуальных машин.

• Настройка DNS-записей.

• Выпуск сертификатов через PKI (используем Vault).

• Развертывание балансировщиков нагрузки (по запросу).

• Установка Kubernetes-кластера.

• Настройка централизованной авторизации (используем LDAP).

• Установка базовых модулей и компонентов в кластер.

Например, в каждом Kubernetes-кластере мы разворачиваем локальный Vault — он отвечает за хранение инфраструктурных секретов и локальное PKI.

• Возможность распараллелить задачи и ускориться, разворачивать много кластеров сразу.

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

• Гибкая настройка параметров и результатов «парой кнопок».

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

Что осталось за кадром

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

Мы не управляем конечными сервисами. Для этого в инфраструктуре уже есть (или будет) отдельный IaC-уровень. Наша задача — развернуть базовое окружение, остальное оставляем другим инструментам.

Только базовый мониторинг. Мы не углубляемся в мониторинг приложений или бизнес-метрик. В платформе уже есть сбор метрик на Prometheus, а мы передаем их в Victoria Metrics для централизованной агрегации. Поверх этого работают алерты — через наш внутренний агрегатор.

Ограниченное число платформ развертывания. Мы сразу ограничили перечень поддерживаемых инфраструктур. Это те платформы, с которыми уже работаем, — K2 Cloud, zVirt и VMware. Расширение платформ возможно, но за рамками текущего релиза.

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

Сценарии применения

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

Изначальный запрос выглядел так: «Нужно быстро развернуть кластер с необходимыми компонентами за несколько минут». Желательно — без участия инженеров: пользователь запускает процесс через интерфейс и получает готовое окружение.

Развертывание однотипных окружений на базе K8s кластеров

⇓

Централизованное управление (шаблонизация, настройки)

⇓

Портал самообслуживания (пользователь сам себе DevOps)

Такой подход оправдан, если:

• нужно регулярно поднимать однотипные стенды;

• требуется быстрая и воспроизводимая автоматизация;

• есть потребность в самообслуживании со стороны внутренних пользователей;

• важно сократить нагрузку на техническую команду.

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

Наши примеры — это демостенды.

Архитектура решения

Ключевые компоненты HyperDrive

Ядром HyperDrive стал Kubernetes-кластер, внутри которого развернуты сервисы: Vault, HyperDrive-бэкенд, Vault Wrapper для автоматической регистрации K8s-кластеров с типом авторизации Kubernetes на Vault, а также сервисы Victoria Metrics.

Начнем с левой части, где описаны сервисы, которые мы написали:

• Cluster Manager — ядро бэкенда, оркестрирует все задачи сверху.

• Vault Wrapper — регистрирует кластеры в Vault с типом авторизации K8s.

• Template Service — отвечает за любой процессинг файлов. Мы с помощью него рендерим Terraform-манифесты, прокатываем GitOps-шаблоны и так далее.

• HyperMon — нужен для агрегации метрик с разных инстансов VictoriaMetrics и предоставления правильного локатора ресурсов в зависимости от платформы. Это нужно, чтобы каждый кластер знал, куда отправлять свои метрики.

Сервисы, к которым подключаются эти бэкенды:

• StarVault — это наша собственная и улучшенная реализация Vault, которую мы разработали после перехода HashiCorp на BSL-лицензию. При этом вы можете использовать и оригинальный Vault — API у них полностью совместимы, все будет работать одинаково.

На основе нашего Vault:

• Сервис PKI — для централизации наших компонентов и автоматизации работы с выпуском общих сертификатов.

• Secret Storage DB — центральное хранилище секретов. Храним в key-value. Нужно, чтобы Cluster Manager сохранял важные данные у себя.

• Victoria Metrics — для централизованного хранения всех Metrics-кластеров, которые к нам поступают.

Вся система также взаимодействует с рядом дополнительных инфраструктурных сервисов:

• DNS — используется провайдер, соответствующий выбранной платформе (например, bind9 on-prem или встроенный DNS в K2 Cloud).

• Postgres — здесь мы храним все несекретные данные для работы HyperDrive.

• Балансировщики нагрузки — настраиваются при необходимости, если указаны в параметрах кластера.

• S3 — используется для хранения состояний Terraform и вспомогательных файлов.

• IPAM — наш собственный модуль для управления IP-адресами, входит в состав HyperDrive «из коробки».

• Git — для хранения конфигураций и GitOps-репозиториев мы используем GitLab и его встроенный IP.

Объясняем выбор архитектуры

Мы используем Nova вместо ванильного Kubernetes, потому что в Nova Container Platform уже предустановлены необходимые обвязки: компоненты для логирования, мониторинга, безопасности и другие инфраструктурные модули. Это позволяет не тратить время на их ручную настройку.

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

Почему не Open Source «с нуля»? Все, о чем мы рассказываем, действительно можно реализовать на базе Open Source. Но поскольку Nova и StarVault — это наши решения, и они уже содержат все нужное, мы используем их, чтобы ускорить разработку и упростить поддержку.

Чтобы построить подобное на K8s+, нужны мониторинг, логирование и инфраструктурные модули.

Наш план такой:

• Выбираем и настраиваем параметры и тип VM.

• Самостоятельно определяем конфигурацию или пользуемся готовыми рекомендациями.

• Распределяем и привязываем модули к существующей инфраструктуре, определяем правила сетевого взаимодействия.

Модули и зачем они нужны

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

• мастер-узлы — для управления Kubernetes-кластером,

• воркер-узлы — для запуска пользовательских приложений,

• инфраструктурные узлы — для развертывания системных компонентов, таких как FluxCD, Cilium, Hubble, Prometheus, модули безопасности и логирования.

Такой подход позволяет структурировать развертывание и упростить настройку каждого типа узлов.

Мы позволяем пользователю выбрать маппинг (маппинг — это правила соотношения модуля и минимальных/рекомендуемых типов виртуальных машин). Он нужен для сервиса рекомендаций, чтобы конечный пользователь мог не задавать все параметры, а просто нажать кнопку «Создать кластер», и в зависимости от типа и маппинга система подберет автоматически рекомендуемые параметры.

Для рекомендуемых параметров мы задаем базовые настройки — такие как тип виртуальной машины, количество CPU, объем RAM и размер дисков. Например:

• если используется платформа K2 Cloud, то выбирается преднастроенный тип инстанса (predefined flavor);

• если используется zVirt или VMware — характеристики задаются вручную, включая диски, исходя из потребностей модуля.

Также можно задать ограничения — строгие или гибкие. Пример строгих ограничений: в высокодоступном кластере всегда должно быть ровно три мастер-узла и ровно три инфраструктурных узла — не больше и не меньше. Если ограничения гибкие, пользователь может изменить настройки под свои задачи. Вид ограничений задается отдельно для каждого модуля.

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

Для каждого модуля мы задаем веса: доли, с которыми он должен разворачиваться в каждой зоне. Эти веса система использует для автоматического распределения модулей между зонами согласно заданным правилам.

Как мы решали проблему с retry и фазами жизненного цикла кластера

Краткий summary по жизненному циклу кластера.

Этапы деплоя кластера

PENDING — начальный этап. На этом этапе система:

• получает IP-адреса из IPAM;

• генерирует SSH-ключи;

• берет общие сертификаты и приводит их к нужному формату;

Затем данные передаются в Template Service, который обогащает их и возвращает итоговые манифесты.

Развертывание виртуальных машин — происходит после получения манифестов.

Настройка балансировщиков нагрузки (опционально). Если пользователем запрошены балансировщики, они разворачиваются на этом этапе. Сейчас используется HAProxy. Возможна последующая доработка этой части.

DEPLOYING_NOVA — стадия установки Kubernetes-кластера.

Постинсталляционные задачи. После установки могут применяться дополнительные патчи и настройки.

Переход в целевой статус. Кластеры переводятся в один из следующих статусов:

• RUNNING — работает;

• UPDATING — обновляется;

• DELETING — удаляется;

• UNKNOWN — состояние не определено;

• FAILED — произошла ошибка.

Обработка ошибок и Retry

На каждом этапе пользователь получает понятное сообщение о результате. Если произошла ошибка, она отображается с указанием, на каком этапе это случилось. Это не подробный StackTrace, но информации достаточно, чтобы оформить задачу в Jira.

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

Шаги 0-4. Как мы создаем инфраструктуру

Разберем пошагово, как мы получаем результат.

0. Работа с SSH-ключами и сертификатами.

На каждом этапе деплоя нового кластера на фазе PENDING мы всегда создаем (или переиспользуем) несколько сущностей:

SSH-ключи (публичный и приватный), которые впоследствии сохраним в Vault. Это необходимо, чтобы обеспечить доступ автоматизации к этому кластеру и в дальнейшем им управлять, так как Kubernetes раскатывается поверх уже готовых виртуальных машин с образами операционных систем.

Intermediate-сертификат. По одному на каждый тип кластера, чтобы избежать перегрузки Vault при пересборке CRL, если в системе более 30 промежуточных сертификатов. Выбранный сертификат извлекается из Vault, шифруется с помощью OpenSSL, сохраняется в KV-хранилище, затем попадает в виде секрета в целевой кластер.

Дальше следуют четыре шага:

1. Конфигурация сетевой инфраструктуры. Любой деплой Kubernetes-платформы начинается с подготовки базовой инфраструктуры. Поэтому первым шагом готовим все базовые секреты и выделяем IP из IPAM.

2. Подготовка базовых ресурсов. Создаётся Terraform-задача (Job) с нужным содержимым. Секреты передаются в нее через аннотации.

3. Подготовка DNS-записей. После создания базовой инфраструктуры создаются DNS-записи, необходимые для платформы и указанные пользователем.

4. Проверка готовности инфраструктуры. Поскольку системы мониторинга на этом этапе еще не развернуты, мы используем собственные кастомные чекеры. Они проверяют:

• доступность SSH-баннера на каждой виртуальной машине;

• прохождение проверки King по ACMP.

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

Как мы создаем виртуальные машины

Виртуальные машины создаем так:

На этапе CREATING_VMS, система отправляет запрос к Template Service и получает Terraform-манифесты. Обработав Terraform-манифесты, несекретные данные она сохранит в ConfigMap. Секретные же будут переданы через аннотации в конкретной job при запуске Kubernetes-кластера.

Процесс начинается со статуса Pending, который означает, что активные проверки не выполняются. Следующий этап — статус Created, в который виртуальная машина (VM) переходит после успешного выполнения Terraform Job, при отсутствии ошибок.

Далее запускаются внутренние проверки: осуществляется ICMP-пинг и проверяется доступность SSH-баннера. В зависимости от результатов, VM переводится в статус Online или Offline.

На ключевых этапах предусмотрен механизм повторных попыток (retry), поскольку возможны случаи, когда аннотации не срабатывают, и контейнер возвращает ошибку доступа. Использование backoff-интервала увеличивает вероятность успешного развертывания: при повторном запуске pod аннотации применяются повторно на уровне issue.

Затем переходим к следующим стадиям. Но сначала расскажу, что у нас в контейнере с Terraform.

Что в контейнере с Terraform

Мы используем фиксированные версии Terraform, его провайдеров и модулей. Вот особенности контейнера:

• Воспроизводимость — зафиксированные версии позволяют повторно запускать инфраструктуру с предсказуемым результатом.

• Стабильность состояния — фиксированная версия предотвращает рассинхронизацию state-файлов и ресурсов в случае, если провайдеры инфраструктуры (например, AWS, GCP и другие) внесут несовместимые или радикальные изменения в новые версии.

• Не нужно скачивать зависимости при каждом деплое, весь набор запускается в полном Air-Gap режиме, без инициализации через интернет. Из локального образа забираются локальные провайдеры, и мы дальше с ними работаем.

• Terraform запускается через Kubernetes Jobs (по типу операции). Это может быть updating, creating или deleting. Соответствующие команды подаются на этот уровень автоматически.

Теперь немного кода. В приведенном ниже блоке показана основная логика работы для Terraform-модулей на примере для Terraform-провайдера K2 Cloud:

module "{{ module_name }}" {
source = "../modules/ec2"
for_each = {
{% for vm_name, vm in instances.items() %}
"{{ vm_name }}" = {
  private_ip = "{{ vm.private_ip }}"
  public_ip = {{ "true" if vm.public_ip else "false" }}
  subnet_id = "{{ vm.subnet_id }}"
  security_group_ids = {{ vm.security_group_ids }}
  instance_type = {{ vm.instance_type }}
},
{% endfor %}
}

На практике основная магия реализуется на уровне цикла for_each. Мы не используем count, так как каждый элемент в for_each представляет отдельную виртуальную машину, а ключ используется как ее имя.

Для каждой ВМ обязательно указываем приватный IP-адрес, заранее выделенный через IPAM. Если пользователь указал, что некоторые ВМ должны быть с публичным доступом, добавляем соответствующие ассоциации.

Передаем список security_groups_ids для изоляции кластера от остальных. Также задаем instance_type, который в случае K2 Cloud представляет собой один из предопределенных конфигурационных профилей — с 2 или 4 vCPU и аналогичным объемом оперативной памяти.

После обработки всех элементов for_each, цикл завершается. Отдельно важно: используется связка Terraform + Jinja. Модуль на Python применяем для генерации финальной конфигурации, которая затем рендерится в ConfigMap.

Как мы работаем с K8s Jobs

• Изоляция задач. Каждая инфраструктурная операция выполняется в отдельном контейнере. У нас есть изоляция на каждом деплое кластера, то есть мы создаем новую операцию так или иначе, поэтому они не пересекаются. States у них тоже хранятся в разных местах. Такой подход гарантирует, что все будущие кластеры изолированы на уровне job и state, и операции, которые будут с ними проводиться, не затронут ресурсы других кластеров. 

• Интеграция с Vault. Безопасное использование секретов через аннотации Vault. В ConfigMaps мы храним несекретные данные. Все переменные, которые нам нужны для работы, мы передаём через аннотации.

• ConfigMap используется для передачи конфигурационных данных и манифестов без необходимости изменения исходного кода. С помощью ConfigMap можно передавать только несекретные параметры конфигурации, как это определено в рамках модуля. Содержимое, подготовленное для мастер-нод, воркер-нод и инфраструктурных узлов, встраивается в соответствующие контейнеры или передается в контейнеры, запускаемые через Kubernetes Jobs.

• Автоматический retry. Настроены повторные попытки при временных сбоях (backoffLimit). Автоматический retry нужен для случаев, когда не отрабатывает Vault annotation или в нем происходит временный сбой. Тогда мы не сразу возвращаем ошибку, а пробуем еще раз.

Как мы работаем с DNS

• DNS-записи создаются через Terraform. У нас стоят наблюдатели, которые сверяют состояние в IPAM и реальный контент из наших FQDN и wildcards, которые мы создаем для кластера.

• В зависимости от платформы, где запускаем кластер, используются разные провайдеры. Например, в ЦОДе для bind9 on-prem используем hashicorp/dns (RFC 2136), который создает DDNS-ресурсы. В облаке используем K2 Cloud Provider, так как у него есть внутренний DNS.

• При любых изменениях инфраструктуры (создание, обновление, удаление VM), DNS-записи автоматически обновляются. Обязательно будет запущена новая job, которая опишет желаемое состояние.

• Гарантирована идемпотентность процесса (отсутствие дублей и конфликтов при повторных запусках), так как мы полностью изолируем эти jobs.

И вот у нас создана инфраструктура.

Шаг 5. Очередь кластера

Пятый шаг — создание очереди кластера:

Установка внутреннего Vault на мастер-узлах вне кластера K8s. Он используется для настройки транзитной авторизации по OIDC через собственные компоненты, организации внутреннего центра сертификации (PKI) для выдачи сертификатов etcd/Kubelet и передачи начальных секретов, необходимых для работы платформы.

Развертывание K8s-кластера и деплой Nova с модулями. Разворачиваем Kubernetes-кластер и деплоим Nova с необходимыми модулями. После инициализации кластера устанавливаем дополнительные модули, настраиваем аннотации, переводим кластер в рабочее состояние. После этого сохраняем информацию о кластере в систему HyperDrive, возвращаем токены для доступа к Vault, передаем дефолтный kubeconfig для дальнейшего управления кластером, передаем данные пользователя kube-admin, необходимые для начальной авторизации через OIDC-провайдер.

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

Эксплуатация. Кластер можно обновить на доступную новую версию, масштабировать горизонтально или вертикально, или удалить, если он больше не нужен.

Архитектура Vault 1 + N

Центральный Vault используется как основной PKI-центр и отвечает за выдачу сертификатов, которые запрашивают пользователи. В конечном (локальном) Vault разворачивается отдельная PKI-структура для генерации сертификатов, используемых сервисами etcd и kubelet.

Также настраивается OIDC-провайдер, который используется для аутентификации всех приложений внутри кластера, включая Grafana и Open-Source-компоненты. Все дополнительные модули также изначально настраиваются на работу через этот OIDC-провайдер.

При необходимости, в конечном кластере можно подключить компонент StarVault к существующей централизованной системе авторизации. В нашем случае используется FreeIPA, к которой осуществляется подключение через LDAPS.

GitOps

Важно сказать про управление репозиториями и доступом через GitLab. У нас это основной инструмент, поэтому весь наш код автоматизации шаблонизирован.

Для каждой задачи создаются форки целевых репозиториев, в которые добавляется базовый контент. При этом автоматически генерируется Project Access Token — он необходим для доступа FluxCD к содержимому репозитория.

После создания репозитория в него загружаются начальные секреты, данные сохраняются в Vault, а далее производится подстановка значений: например, имя кластера в Ingress заменяется на актуальное имя из DNS, полученное от IPAM-контроллера.

Настройка FluxCD

FluxCD создает несколько ресурсов:

• Обычный ванильный Secret — используется без аннотаций и без привязки к центральному Vault, так как не требует централизованного управления.

• GitRepository — указывает на созданный репозиторий с контентом.

• Kustomization — описывает, какие манифесты нужно применить.

Один из Kustomization-ресурсов отвечает за применение других Kustomization-ов. При этом у него установлен параметр prune: false, чтобы при обновлении не удалить существующие ресурсы, даже если они отсутствуют в новой версии манифестов.

Как работает мониторинг

Мониторинг входит в состав контейнерной платформы: мы его деплоим через GitOps и управляем через Prom Operator. Наша задача — обеспечить централизованную агрегацию. 

На этапе задач после инсталляции мы вносим патч в ресурс Kustomization, добавляя конфигурацию Remote Write. При работе в отказоустойчивом режиме настраиваем дублирование по лейблам, чтобы избежать переполнения данных, передаем insert URL для записи метрик.

Это необходимо, чтобы не передавать большой объем метрик между площадками при наличии нескольких кластеров, так как в архитектуре используется несколько экземпляров VictoriaMetrics. Значения insert URL и select URL генерируются сервисом HyperMon и автоматически применяются в патч Kustomization.

HyperMon

HyperMon — централизованный агрегатор мониторинга, позволяющий удобно и эффективно управлять метриками инфраструктуры. 

Мы предоставляем:

Гибкое развертывание. Система поддерживает возможность развертывания дополнительных экземпляров VictoriaMetrics по запросу. Это используется, например, при работе с кластером, генерирующим нагрузочные или специфические типы метрик — для таких случаев может быть развернут отдельный экземпляр, обрабатывающий только эти данные. Поскольку кластеры создаются по GitOps-подходу с использованием базовых модулей, добавление нового инстанса сводится к передаче актуального контента (манифестов и конфигураций) в соответствующий Git-репозиторий. Далее FluxCD применяет изменения автоматически.

Автоматическую очистку. При удалении кластера данные из VictoriaMetrics удаляются автоматически. Это нужно, чтобы метрики не путались.

Изоляцию данных. Метрики изолированы на уровне tenant-ов.

Единое окно мониторинга. HyperMon агрегирует метрики и предоставляет унифицированный API с поддержкой PromQL, чтобы возвращать данные в понятном формате. 

Процесс удаления кластера

Это важный процесс, потому что если не вычистить все ресурсы, они потом могут быть переиспользованы.

Здесь идем в таком порядке:

• При инициализации запроса запускаем Terraform Jobs, которые будут удалять базовые IaaS- и DNS-ресурсы. 

• после завершения Terraform Jobs  удаляем секреты кластера из Vault. 

• Удаляем репозиторий GitLab для модулей и кластеры из мониторинга, чтобы обеспечить чистоту VictoriaMetrics. 

• Удаляем всю метаинформацию из Postgres, освобождаем IP и конфигурации, которые не являются секретными. 

• В завершении удаляем финальные K8s-ресурсы. 

Все: кластер успешно удален.

Магия HyperDrive

Раскрою, что происходит под капотом HyperDrive:

Автоматическая подготовка окружения

• Валидация параметров без участия пользователя.

• Автогенерация и применение конфигураций инфраструктуры и кластеров.

• Хранение секретов в Vault на основании лучших практик.

• GitOps «здорового человека».

Надежность и отказоустойчивость

• Идемпотентность каждого этапа.

• Логирование и отслеживание статуса.

Обработка ошибок

• Возможность повторного запуска этапов.

• Сохранение состояния инфраструктуры (IaC).

• Асинхронное выполнение.

• Kubernetes Jobs для долгих операций (создание ВМ, настройка LB).

• Изоляция и контроль.

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

Функциональность инструмента

UI — точка роста, так как интерфейс — базовый.

Есть и другие фичи, которые не учтены в этих скриншотах.

Если HyperDrive недоступен

Поскольку используется архитектура Vault 1 + N, в каждом конечном Kubernetes-кластере разворачивается локальный экземпляр Vault или отдельный инстанс Vault — в зависимости от конфигурации.

Это означает, что в случае отказа централизованного Vault или HyperDrive последствия будут ограничены:

• станет недоступен центральный PKI;

• нельзя будет запрашивать новые сертификаты от центрального сервера.

Однако локальный PKI, развернутый в каждом кластере, продолжит работать, и текущая функциональность кластера сохранится.

Для инфраструктурных приложений в Vault используется intermediate-CA, что позволяет локальным Vault-инстансам самостоятельно выпускать сертификаты.

Файлы kubeconfig и deployment-config доступны на мастер-узлах: kubeconfig используется для доступа к кластеру, deployment-config содержит описание базовых параметров кластера, включая используемые подсети и токены для доступа к registry.

FluxCD и GitOps-инфраструктура изолированы — они разворачиваются в каждом кластере отдельно. Централизованный подход здесь не применяется.

Мониторинг также реализован локально в каждом кластере. Он позволяет настраивать собственные правила оповещения. Это означает, что даже в случае потери центрального агрегатора, каждый кластер сможет самостоятельно зафиксировать проблему и сообщить о ней.

Утилита nova-ctl предоставляет альтернативный способ управления. После запуска сервисов система автоматически синхронизирует все изменения, выполненные в процессе инициализации.

Таким образом, отказ HyperDrive или центральных компонентов не приводит к потере управления кластерами Kubernetes благодаря распределенной архитектуре и зонтичной модели.

Выводы

Мы планируем усовершенствовать инструмент, добавив: 

• Проактивные алерты. Сейчас у нас есть возможность централизованного мониторинга, поэтому мы можем производить дополнительные операции. Например, запускать Webhook на Cluster Manager, который в случае алерта по использованию CPU на всем кластере более 2 дней 90% произведет его масштабирование в большую или меньшую сторону.

• RBAC и API Tokens. В скоуп нашего внутреннего инструмента не был включен RBAC и его API-токены, поэтому выведем их в скором релизе на внутреннюю команду.

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

• Vanilla K8s + модули. Мы задумались о выпуске комьюнити-версии, поэтому хотим добавить ванильный Kubernetes  с модулями, чтобы исключить vendor lock-in. Там также будет возможность управлять подключаемыми Kubernetes кластерами.

• Hardening. Хотим добавить больше hardening. Это важно, так как сейчас все наши ресурсы, которые создаются в конечном классе, используют kube-admin.

Было и стало в цифрах:

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

Мы можем посчитать стоимость экономии ресурсов в часах: 

В первой строке — что бы было, если бы мы не начинали разработку и продолжали жить по-прежнему. Цифра 240 складывается из estimate по четыре часа на каждый деплой. Так как в месяц порядка 80 деплоев, значит, за квартал — 240 часов. Путем нехитрых прикидок получаем, что разработка HyperDrive, которая заняла 840 часов, в первом квартале 2026 года уже окупится. Мы инвестировали время, которое тратили на рутину, в задачи развития — DevOps-инженеры довольны, автоматизация работает, и мы всегда получаем понятный результат.

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