Как управлять кластерами как системой, а не набором инструментов

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

В Nova Container Platform для таких задач развивается Cluster Manager: он показывает список кластеров, хранит часть параметров и позволяет запускать операции через интерфейс и API.

Меня зовут Семен Месилов, я технический лидер Nova Container Platform. В статье расскажу, как мы подошли к этой задаче, и что уже получилось сделать в Cluster Manager.

Где появляется сложность

В инфраструктуре редко бывает один Kubernetes-кластер на всё. Обычно кластеры появляются под разные среды, команды или продукты: отдельный контур для разработки, тестирования, предпрода и прода; где-то — общий кластер для нескольких команд, где-то — выделенный под конкретный продукт или нагрузку.

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

Сам процесс создания кластера тоже редко бывает одинаковым для всех. У каждой компании свои регламенты, инструменты и степень автоматизации. Где-то кластер заказывают через внутреннюю заявку, где-то его поднимает команда эксплуатации, где-то развёртывание завязано на внутреннюю облачную платформу или managed-сервис.

Общий контур часто похож: появляется запрос на новый кластер, согласуются ресурсы, сети и размещение, после чего команда эксплуатации использует свой набор инструментов. Это может быть Terraform для инфраструктурной части, Ansible, kubeadm, bash-скрипты, CI/CD-пайплайны или внутренняя автоматизация. Затем заказчику передают данные для работы с кластером: kubeconfig, креды, сертификаты, инструкции и другие артефакты.

Сложность начинается не в одном конкретном инструменте, а на стыках между ними. Описание кластера может лежать в Git, инфраструктурная часть — в Terraform, развёртывание — в Ansible, скриптах или пайплайнах, доступы — в Vault, файлах или у конкретных людей, состояние — в мониторинге, CMDB, wiki или таблицах. У каждого инструмента своя задача, и ни один из них сам по себе не обязан показывать полную картину.

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

Как это было устроено в Nova: nova-ctl и Universe

В Nova Container Platform до появления Cluster Manager основным инструментом развёртывания был nova-ctl — консольная утилита для создания кластеров и выполнения базовых операций с ними.

Этот процесс опирался на Universe — специализированный репозиторий для работы NCP в изолированных офлайн-средах. Клиент разворачивал Universe в своём контуре и получал локальный источник компонентов, необходимых для установки и дальнейшей эксплуатации кластеров Nova.

На практике сценарий создания кластера через nova-ctl выглядел так:

• Инженер запускал утилиту, скачивал пример конфигурационного манифеста в YAML для своей инфраструктуры в изолированной среде и заполнял его вручную. В манифесте нужно было указать данные о самом Universe, параметры провайдера, хост-группы, если они используются, и ресурсы по узлам.

• После этого инженер отправлял команду на создание кластера и передавал SSH-ключ для подключения к узлам.

• Дальше nova-ctl запускал процесс развёртывания. Если использовался инфраструктурный провайдер, сначала создавались виртуальные машины. Если инфраструктура была подготовлена заранее, использовались уже готовые узлы.

• После этого запускалось развёртывание Kubernetes, а затем в кластер доставлялись компоненты Nova.

Сам подход был рабочим и привычным для администраторов, которые уже использовали nova-ctl. Можно было держать готовые манифесты, править нужные поля и запускать операции из командной строки. Но это всё равно оставалось консольным сценарием: нужно было знать структуру манифеста, понимать, какие параметры обязательны, где взять данные Universe и провайдера, как описать хост-группы и не ошибиться в значениях.

Cluster Manager появился в Universe как другой способ выполнить те же базовые действия, но через интерфейс. Nova-ctl остаётся консольной утилитой, а Cluster Manager даёт UI-путь для работы с кластерами внутри NCP.

В интерфейсе видны все кластеры, их статусы и детали. Cluster Manager хранит конфигурации, сертификаты и ключи, позволяет запускать операции и сразу переходить в консоль NCP. То есть это не замена Universe и не отказ от nova-ctl, а расширение сценариев работы с кластерами в изолированных средах.

Зачем появился Cluster Manager

Cluster Manager не задумывался как замена nova-ctl или существующей автоматизации Nova. Скорее это следующий слой над уже рабочим механизмом развёртывания: часть шагов, которые раньше требовали манифеста, документации и ручной подготовки данных, перенесли в интерфейс и API.

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

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

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

Постепенно из этого складывается единое представление кластеров. Кластер перестаёт быть только результатом разового запуска nova-ctl. В Cluster Manager у него есть конфигурация, текущий статус, связанные задачи и набор доступных действий: создать кластер, запустить обновление, масштабировать, проверить сертификаты или выполнить другие операции в зависимости от задачи пользователя.

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

В итоге Cluster Manager появился не как «ещё одна тулза для кубера», а как следующий шаг в развитии Nova Container Platform: от работы с отдельными манифестами и командами — к управлению кластерами через интерфейс, API и сохранённое состояние.

Как выглядит создание кластера через Cluster Manager

В Cluster Manager работа начинается со списка кластеров: инженер видит, какие кластеры уже есть, в каком они статусе, и может перейти к созданию нового.

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

Сначала выбираются провайдер, базовые настройки, учётные данные для подключения к API провайдера и желаемая версия NCP. Это важно: состав параметров может отличаться между версиями платформы, и при работе через манифест такие различия приходилось учитывать вручную. В Cluster Manager доступные версии подтягиваются из конкретного Universe, поэтому инженер выбирает из того, что реально доступно в этой среде.

Затем задаются общие параметры кластера: имя, базовый DNS-домен, SSH-ключ для подключения к узлам.

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

После запуска задача уходит в очередь. Инженеру не нужно вести процесс вручную по шагам: можно запустить создание следующего кластера или заняться другой операцией, а в Cluster Manager отслеживать статус выполнения. Одновременно система может выполнять до 10 задач, остальные остаются в очереди.

Cluster Manager при этом не меняет сам механизм развёртывания Nova. Он встраивается в существующий процесс и запускает компоненты, которые уже отвечают за создание виртуальных машин, установку Kubernetes и доставку компонентов платформы.

Что происходит под капотом

После заполнения формы Cluster Manager собирает данные в структуру, близкую по смыслу к манифесту, который раньше заполняли вручную для nova-ctl. Формат другой, но задача та же: передать системе все параметры, необходимые для создания кластера. При этом данные о Universe Cluster Manager добавляет сам — их не нужно отдельно указывать в форме.

Дальше интерфейс обращается к бэкенду Cluster Manager через API. Бэкенд взаимодействует с Nova-management-api — специализированным сервисом, который отвечает за развёртывание и управление платформой. После этого запускается процесс создания кластера, аналогичный работе через nova-ctl.

То есть Cluster Manager не заменяет внутренний механизм установки Nova. Он даёт другой способ запустить тот же базовый процесс: не через консольную утилиту и манифест, а через интерфейс и API. Дополнительно он хранит часть данных, показывает список кластеров, их статусы и детали, а также отображает выполнение задач — тех самых действий, которые инженер запускает с кластером.

Куда развивается Cluster Manager

Дальше Cluster Manager развивается в двух направлениях: как инструмент для создания кластеров Nova с меньшим количеством ручных шагов и как общий API для продуктов экосистемы Orionsoft.

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

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

Ещё один важный для нас сценарий — использование Cluster Manager внутри экосистемы. Он уже применяется в сертифицированной ФСТЭК версии zVirt и Cloudlink как базовый API для продуктов, которым нужно работать с кластерами Nova. Например, в zVirt управление кластерами Nova интегрировано прямо в интерфейс виртуализации: инженер может работать с кластерами без перехода в отдельный инструмент. Для Cluster Manager это уже не только пользовательский интерфейс Nova Container Platform, но и точка интеграции для соседних продуктов экосистемы, которым нужно работать с кластерами Nova.

Сложность Kubernetes-инфраструктуры никуда не исчезает. Зато её можно меньше перекладывать на инженера: убирать ручные шаги, переиспользовать готовые конфигурации и давать продуктам Orion soft один общий механизм работы с кластерами Nova.