Изменено 2026-07-01 в 19:41

Как развернуть кластер

Инструкция по развёртыванию клиентского кластера в GUI для Shturval v2, VMware vSphere, oVirt, OpenStack, Yandex Cloud, vCloud Director и Basis Dynamix.

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

Предусловия (проверьте перед началом)

Перед нажатием Создать кластер или Добавление кластера убедитесь:

Кластер управления в статусе Готов — Где смотреть: Кластеры → список кластеров.
Пул IP-адресов создан, если он нужен для вашего сценария (облегчает развёртывание с внутренними балансировщиками и провайдерами инфраструктуры VMware vSphere, oVirt и подобными, Shturval v2) — Где смотреть: Провайдеры → Пулы IP-адресов.
В используемом пуле минимум 2 свободных адреса, если вы выдаёте VIP из пула — Где смотреть: страница пула, колонка «Статус».
Экземпляр провайдера создан — Где смотреть: Провайдеры → Конфигурация провайдеров.
Проверка подключения провайдера пройдена — Где смотреть: зелёная галочка на экземпляре.
Для провайдеров с шаблонами ВМ/образами: шаблон добавлен для нужной версии Kubernetes — Где смотреть: карточка экземпляра провайдера.
Пул IP привязан к экземпляру провайдера, если используете пул — Где смотреть: редактирование экземпляра, поле «Пул IP».
Проверка пересечения подсетей при создании кластера: подсети подов/сервисов и VIP согласованы с инфраструктурой — Где смотреть: шаг мастера «Основные данные».

Обратите внимание! Для OpenStack, Yandex Cloud, vCloud Director, Basis Dynamix пулы IP не используются — адреса задаются иначе (часто через внешние балансировщики). См. соответствующую вкладку провайдера.

Если что-то не выполнено — перейдите к странице Как устроена работа с провайдерами в платформе. Общие требования к узлам и сети — на странице Требования.

Кратко о провайдерах

Провайдер	Когда выбрать	Подготовка узлов
Shturval v2	«Голые» хосты, SSH	Хосты и ОС, без шаблона ВМ
VMware vSphere	vCenter	Шаблон ВМ (stc), загрузка в vSphere
oVirt и аналоги	zVirt, oVirt, HostVM, РЕД Виртуализация, ROSA Virtualization	Шаблон ВМ, DHCP в профиле VNIC
OpenStack и аналоги	VK Cloud, Selectel и др.	Образы, VPC, security groups
Yandex Cloud	Облако Yandex	Образ с `--keep-cloud-init`, VPC
vCloud Director	Организация vCloud	Каталоги, шаблоны, DHCP в сети
Basis Dynamix	Среда Basis Dynamix	Шаблоны/образы, настройка LB после создания

Рекомендация для первого раза: VMware vSphere или Shturval v2.

Где в платформе создать кластер

Откройте раздел Кластер и нажмите Добавление кластера.
Выберите тип провайдера и задайте Имя кластера (см. скриншот ниже).
Пройдите шаги мастера: основные данные (экземпляр, сеть и точки входа по сценарию провайдера, при необходимости шаблон или образ), узлы Control Plane и Worker, сертификат, выбор сервисов, проверка данных → Создать (см. скриншот ниже).

Иллюстрация: Где в платформе создать кластер

Поле	Назначение
Имя кластера	Уникальный идентификатор. Ограничено 37 символами: имя кластера используется при формировании лейблов для связанных объектов, длина которых ограничена (63 символа)

Подробные поля мастера и особенности среды — на вкладках в разделе «Развёртывание по провайдерам».

Развёртывание по провайдерам

Ниже — предварительные требования, ход работы в GUI, поля мастера (шаги 1–4 или эквивалент), особенности среды и вызов API для каждого провайдера. Общие шаги установка сертификата и выбор сервисов вынесены после вкладок.

После заполнения полей провайдера в мастере перейдите к разделам «Установка сертификата» и «Выбор сервисов», затем завершите проверку данных и создание кластера.

Shturval v2

Предварительные требования

Настроенный экземпляр провайдера Shturval v2 с добавленными хостами;
Пул IP-адресов с свободными адресами для KubeAPI и Ingress (необязательно, упрощает выбор VIP-адресов при использовании внутренних балансировщиков для Kube-API/Ingress);
Хосты с ОС из списка поддерживаемых, SSH-доступ.

Преимущество: Шаблон ВМ не нужен — платформа разворачивает Kubernetes напрямую на выбранных хостах. Подробнее о модели без шаблонов ВМ и Cluster API см. Создание узлов при развертывании клиентского кластера.

Процесс в GUI

Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для Shturval v2:

Заполните основные данные (базовый или расширенный режим): экземпляр, версию платформы, сетевые точки входа (см. таблицу), при необходимости внешние балансировщики, подсети и профиль кластера.
Настройте Control Plane и Worker-группы: выбор хостов, масштабирование, селекторы в расширенном режиме.
Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер.

Шаг 1: Основные данные

На шаге «Основные данные» поля доступны в базовом режиме и в режиме расширенных настроек (тумблер «Показать расширенные настройки»). При переключении из расширенного режима в базовый значения в скрытых полях теряются.

Базовый режим — минимальный набор: VIP для управляющего доступа к кластеру и VIP Ingress, при необходимости выбор адресов из пула экземпляра. Расширенные параметры ИБ, внешние балансировщики и явные CIDR подов/сервисов в этом режиме не задаются (используются значения по умолчанию платформы).

Скриншот: основные данные в базовом режиме

В базовом режиме задаются:

Поле	Назначение
Экземпляр	Экземпляр Shturval v2; если один — выбирается автоматически.
Версия платформы	Версия платформы «Штурвал», с которой будет установлен кластер
Версия Kubernetes	Версия Kubernetes в соответсвии с выбранной версией платформы
Адрес API-сервера кластера	IP или FQDN для KubeAPI; можно ввести вручную или выбрать свободный IP из пула, привязанного к экземпляру. Доступно копирование значения.
VIP-адрес для Ingress	IPv4 во внутренней подсети узлов или из пула; будет настроен на одном из Worker для системного Ingress. Доступно копирование.

Если у экземпляра задан пул IP, выпадающие списки показывают только свободные адреса пула. Если свободен один адрес, его можно указать либо для API, либо для Ingress; иначе задайте адреса вручную или расширьте пул.

Расширенный режим добавляет поля внешней балансировки, подсетей и профиля.

Скриншот: расширенные основные данные

Поле	Назначение
Адрес API-сервера	Как в базовом режиме; при использовании внешнего LB для API — укажите FQDN, на который настроен балансировщик (см. ниже).
VIP-адрес для Ingress и DNS-запись Ingress	IPv4 и/или Wildcard FQDN для Ingress. Если используете внутренний балансировщик для Ingress, доступны оба поля. DNS-запись Ingress ограничена 53 символами, чтобы итоговый `commonName` для cert-manager не превышал допустимую длину.
Использовать внешний балансировщик для Ingress	При включении используется haproxy; при внутренней схеме балансировка на API может не применяться, трафик идёт на VIP. При внешнем LB для Ingress остаётся поле DNS-запись Ingress (Wildcard FQDN).
Использовать внешний балансировщик для API-сервера	По умолчанию выключено. Если включено — в поле Адрес API-сервера укажите FQDN внешнего балансировщика. Балансировщик должен быть настроен до начала развёртывания кластера.

Скриншот: внешний балансировщик для API

Скриншот: внешний балансировщик для Ingress

Поле	Назначение
Установить расширенные параметры информационной безопасности	Secret Encryption для etcd, TLS-соединение с Kubelet и преднастроенная политика аудита.
Подсеть подов	CIDR для Pod; не должен пересекаться с сетью узлов и сервисов. Типичный диапазон: `172.16.0.0/16`.
Подсеть сервисов	CIDR для `ClusterIP`; не пересекается с узлами и Pod. Рекомендуется `10.96.0.0/12`.
Профиль кластера	См. Профили кластеров; по умолчанию — дефолтный профиль.

Перед сохранением проверьте диапазоны на пересечения; см. FQDN и VIP и проверку пересечения подсетей при создании кластера.

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

FQDN в кластере зависят от Ingress:

при DNS-записи Ingress: *.<DNS-запись-Ingress>;
при VIP Ingress: *.<CLUSTER_NAME>.ip-<VIP-Ingress>.shturval.link.

Шаг 2–3: Конфигурация узлов

В отличие от провайдеров с шаблонами ВМ, узлы — это хосты экземпляра (роли и лейблы задаются при добавлении хостов или в провайдере).

Control Plane — нечётное число узлов, не больше 5. В блоке Потенциально доступные хосты показаны хосты с ролью controlplane (или согласно селектору). Если хостов нет — добавьте их в экземпляр провайдера.

Скриншот: Control Plane, базовый режим

В расширенных настройках доступен селектор хостов (лейблы, выражения); по умолчанию добавлен лейбл роли controlplane.

Скриншот: Control Plane, селектор

Worker-группы — по умолчанию две защищённые группы по три узла: default и infra. Их можно создавать без добавления хостов (количество 0), тогда останутся MachineDeployments для последующего масштабирования. Можно добавить пользовательские группы, копировать настройки между группами, дублировать конфигурацию.

Скриншот: группы Worker

Для каждой группы: ручное или автоматическое масштабирование (минимум узлов в GUI обычно не ниже 2), в базовом режиме — роль хостов (workers, infra и т.д.; роль controlplane для Worker недоступна). В расширенном режиме — селектор хостов с лейблами по умолчанию для группы.

Скриншот: параметры группы Worker, базовый режим

Скриншот: селектор Worker

Обратите внимание! Правило селекторов: лейблы, заданные как совпадение в одной группе, в других группах следует исключать через NotIn (тот же ключ и значение), чтобы хост не попал в две группы одновременно.

Если на старт создания не хватает хостов с нужными ролями/лейблами, часть узлов может не присоединиться: добавьте хосты в провайдере и проверьте лейблы на странице узла (Лейблы и аннотации / Cluster API).

Рекомендуемые ресурсы хостов: требования к клиентскому кластеру.

Далее — общий шаг «Установка сертификата» и «Выбор сервисов».

Особенности Shturval v2

Без шаблона: Платформа устанавливает Kubernetes на «голые» хосты с предустановленной ОС.
Хосты: Добавляются в экземпляр провайдера. Требуется SSH-доступ (ключ или пароль). Хосты должны быть в одной подсети.
Ресурсы: CPU, RAM, диск задаются на хостах. Платформа не создаёт ВМ — использует существующие.
Рекомендуется для: Первого кластера, тестовых стендов, bare metal.