Как развернуть кластер
Инструкция по развёртыванию клиентского кластера в 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 символа) |
Подробные поля мастера и особенности среды — на вкладках в разделе «Развёртывание по провайдерам».
Удаление PV при удалении кластера
Для провайдеров oVirt (и совместимых), VMware vSphere, OpenStack / VK Cloud / Selectel, vCloud Director и Yandex Cloud на шаге Основные данные доступен выбор Удалить PV при удалении кластера с включенной интеграцией CSI, если интеграция CSI разрешена в экземпляре провайдера.
При включённой интеграции CSI тома живут не на дисках узлов, а во внешнем хранилище провайдера. Кластер и виртуальные машины можно удалить — диски CSI при этом остаются и продолжают занимать место в инфраструктуре. Выбор задаёт, чистить ли эти диски вместе с кластером.
Скриншот: поле удаления PV на шаге Основные данные
| Значение | Что происходит при удалении кластера |
|---|---|
| Нет (по умолчанию) | PV в кластере не зачищаются. Диски на стороне виртуализации или облака остаются. |
| Да | Перед удалением кластера удаляются PV в кластере. |
Выбор при создании кластера приоритетнее политики в профиле кластера. Если при создании в GUI или shtil параметр не передан, берётся значение из профиля. Если его нет ни в запросе, ни в профиле — PV не удаляются.
Итоговая настройка кластера — в ресурсе ClusterConfig (API-группа cluster.shturval.tech) в кластере управления. Имя объекта и неймспейс совпадают с именем кластера. Параметр — spec.deletePersistentVolumes: true — PV удаляются перед удалением кластера, false или поле отсутствует — нет. Описание ресурса: Кастомные ресурсы платформы.
Где смотреть:
- в GUI: кластер управления → Администрирование → Кастомные ресурсы → API-группа cluster.shturval.tech → ClusterConfig → имя кластера;
- в CLI:
kubectl -n <имя-кластера> get clusterconfig <имя-кластера> -o yaml
Выбор шаблона ВМ
Для всех провайдеров, кроме Shturval v2, на шаге Основные данные после выбора версии платформы может быть доступно поле Шаблон ВМ.
Выбрать шаблон ВМ возможно, только если в выбранном экземпляре для этой версии платформы добавлено несколько шаблонов ВМ с одной версией Kubernetes. Если шаблон один, поле не отображается.
При обновлении кластера, если для целевой версии Kubernetes в экземпляре несколько шаблонов ВМ, платформа выбирает первый по алфавиту и применяет его ко всем группам узлов. Чтобы при обновлении гарантированно выбрался нужный шаблон, добавьте один шаблон следующей версии.
Развёртывание по провайдерам
Ниже — предварительные требования, ход работы в 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-доступ по ключу. Пароль для
sudo, если он требуется, задаётся в учётных данных хоста — см. Как добавить пароль для команд sudo. При создании кластера управления тот же пароль задаётся в интерфейсе установки или из консоли — см. Пароль SSH-пользователя для sudo. Хосты должны быть в одной подсети. - Ресурсы: CPU, RAM, диск задаются на хостах. Платформа не создаёт ВМ — использует существующие.
- Рекомендуется для: Первого кластера, тестовых стендов, bare metal.
VMware vSphere
Предварительные требования
- Настроенный экземпляр провайдера VMware vSphere;
- Шаблоны ВМ для нужных версий Kubernetes: можно добавить несколько шаблонов, в том числе с одинаковой версией Kubernetes; подготовка по инструкции по шаблонам (утилита stc), затем загрузка в vSphere;
- Пул IP-адресов с минимум 2 свободными адресами (KubeAPI и Ingress).
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для VMware vSphere:
- Заполните основные данные (базовый или расширенный режим): экземпляр, шаблон провайдера, сетевые точки входа (см. таблицу), версию платформы, при необходимости CSI, внешний балансировщик, подсети и профиль кластера.
- Настройте Control Plane и Worker-группы: число узлов, ресурсы по умолчанию или переопределение, масштабирование.
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер.
Шаг 1: Основные данные
Заполнение доступно в базовом режиме и в режиме расширенных настроек. При переключении из расширенного режима в базовый значения в скрытых полях теряются.
Скриншот: основные данные в базовом режиме
Скриншот: расширенные основные данные
| Поле | Зачем нужно | Особенности |
|---|---|---|
| Экземпляр | Экземпляр vSphere; если один — выбирается автоматически. | — |
| Шаблон провайдера | Определяет версию Kubernetes и пул IP. Шаблон должен быть добавлен в экземпляр провайдера. | Если шаблон один — выбирается автоматически. При привязанном пуле показывается количество свободных IP. |
| Шаблон ВМ | Какой образ ВМ использовать для всех узлов. | Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер. | Зависит от версии Kubernetes в шаблоне. |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы. | |
| Адрес API-сервера кластера | VIP для KubeAPI. По нему подключаются kubectl, дашборды, CI/CD. | Выберите из пула или введите вручную. Должен быть в подсети Control Plane узлов. |
| VIP-адрес для Ingress (базовый режим), VIP-адрес для Ingress и/или DNS-запись Ingress (расширенный) | Точка входа для HTTP/HTTPS. | В расширенном режиме при использовании внутреннего балансировщика можно заполнить и VIP, и DNS-запись. При внешнем балансировщике для Ingress остаётся поле DNS-запись Ingress. DNS-запись Ingress ограничена 53 символами, чтобы итоговый commonName для cert-manager не превышал допустимую длину. |
| Включить интеграцию CSI | vSphere CSI для PersistentVolume. | Требует сервисной роли №2 в vCenter. По умолчанию — нет. |
| Удалить PV при удалении кластера с включенной интеграцией CSI | Удалять ли PV в кластере с включённой CSI. | Да / Нет. По умолчанию Нет. Подробнее: Удаление PV при удалении кластера. |
| Использовать внешний балансировщик | Используется haproxy. | В расширенных настройках. Иначе весь управляющий трафик приходит на VIP. |
| Установить расширенные параметры информационной безопасности | Secret Encryption для etcd, TLS-соединение с Kubelet и политика аудита. | Только в расширенных настройках. |
| Подсеть подов | CIDR для Pod-сети. | 172.16.0.0/16 — типично. Не должна пересекаться с сетью узлов и сервисов. |
| Подсеть сервисов | CIDR для Service (ClusterIP). | 10.96.0.0/12 — по умолчанию. |
| Профиль кластера | Набор политик и параметров кластера. | См. Профили кластеров; по умолчанию — дефолтный. |
Прежде чем задавать подсети, проверьте диапазоны на пересечение: FQDN и VIP, проверка пересечения подсетей при создании кластера.
Если к шаблону/провайдеру не привязан пул IP, адреса вводятся вручную. Требования: VIP для KubeAPI — в подсети Control Plane узлов; VIP для Ingress — в подсети, доступной для балансировщика; адреса не должны совпадать с IP узлов кластера.
Механизм резервирования IP отсутствует. Адрес свободен на момент конфигурации, но к моменту запуска может быть занят — кластер не развернётся. Рекомендуется выделять непересекающиеся подсети под разные кластеры.
FQDN: при DNS-записи Ingress — *.<DNS-запись-Ingress>; при VIP Ingress — *.<имя-кластера>.ip-<VIP-Ingress>.shturval.link.
Шаг 2–3: Конфигурация узлов
Шаблон провайдера выбирается на шаге «Основные данные». На этом шаге задаётся количество узлов и при необходимости — переопределение ресурсов.
Скриншот: Control Plane
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane: количество | 1 — тест; 3 — production (отказоустойчивость). | Для production — 3 узла. |
| Worker: группа default | Узлы для приложений пользователей. | Минимум 2. |
| Worker: группа infra | Узлы для системных сервисов. Разделение снижает конкуренцию за ресурсы с приложениями. | 0 или 3 для production. |
| Ресурсы (CPU, RAM, диск) | Переопределение параметров шаблона для узлов. | См. требования к ресурсам клиентского кластера. |
По умолчанию создаются две группы Worker (default и infra) по три узла; число узлов можно обнулить — останутся MachineDeployments для последующего масштабирования. Доступны ручное и автоматическое масштабирование, копирование настроек между группами, дублирование конфигурации группы.
Скриншот: группы Worker
Скриншот: параметры группы Worker
Особенности VMware vSphere
- Сеть: В выбранной Network (Distributed Port Group) должен работать DHCP — платформа получает IP для создаваемых ВМ автоматически.
- Шаблон: Должен быть подготовлен утилитой stc и загружен в vSphere. Для исходной ВМ в vSphere перед подготовкой шаблона: параметр
disk.EnableUUID = True, аппаратная версия ВМ (совместимость) 15 или выше, контроллер SCSI — VMware Paravirtual. Без корректного шаблона создание завершится ошибкой. - CSI: Для PersistentVolume включите «Включить интеграцию CSI» и настройте права сервисной роли №2 в vCenter (см. провайдер vSphere).
- FQDN: При VIP Ingress —
*.clustername.ip-X-X-X-X.shturval.link. При DNS-записи —*.<DNS-запись-Ingress>.
oVirt и подобные
Предварительные требования
- Настроенный экземпляр провайдера oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA);
- Шаблоны ВМ для нужных версий Kubernetes;
- Пул IP-адресов с минимум 2 свободными адресами.
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для oVirt (или аналога):
- Заполните основные данные (базовый или расширенный режим): экземпляр, шаблон провайдера, сетевые точки входа (см. таблицу), версию платформы, при необходимости CSI, внешний LB, подсети и профиль кластера.
- Настройте Control Plane и Worker-группы: число узлов, ресурсы (cores/sockets/threads, память, диск для oVirt), масштабирование.
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер.
Шаг 1: Основные данные
Заполнение доступно в базовом и расширенном режиме (тумблер «Показать расширенные настройки»). При переключении в базовый режим данные из скрытых полей теряются.
Базовый режим: экземпляр, шаблон провайдера, версия платформы, VIP/FQDN для управляющего доступа к кластеру и для Ingress, CSI. Расширенные параметры ИБ и явные CIDR подов/сервисов не задаются; внешний балансировщик не используется.
Расширенный режим дополнительно: VIP-адрес для Ingress и DNS-запись Ingress (при отключённом внешнем балансировщике для Ingress можно заполнить оба значения), внешний балансировщик (haproxy; при включении для Ingress остаётся поле DNS), расширенные параметры ИБ, подсеть подов, подсеть сервисов, профиль кластера (справка).
| Поле | Зачем нужно | Особенности |
|---|---|---|
| Экземпляр | Экземпляр oVirt (или аналога); если один — выбирается автоматически. | — |
| Шаблон провайдера | Версия Kubernetes, образ ВМ, пул IP. | Один шаблон выбирается автоматически. При пуле показывается число свободных IP. |
| Шаблон ВМ | Какой образ ВМ использовать для всех узлов. | Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
| Адрес API-сервера | VIP/FQDN KubeAPI. | Из пула шаблона или вручную. |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер | Зависит от версии Kubernetes в шаблоне. |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы | |
| VIP-адрес для Ingress и DNS-запись Ingress | HTTP/HTTPS Ingress. | Из пула или вручную; в расширенном режиме можно также указать Wildcard FQDN. Когда использование внешнего балансировщика для Ingress отключено доступно заполнить и VIP, и DNS-запись. |
| Включить интеграцию CSI | oVirt CSI. | Может быть запрещено в шаблоне. |
| Удалить PV при удалении кластера с включенной интеграцией CSI | Удалять ли PV в кластере перед удалением кластера с включённой CSI. | Да / Нет. По умолчанию Нет. Подробнее: Удаление PV при удалении кластера. |
Список IP в выпадающих полях — свободные адреса пула выбранного шаблона. Один свободный IP нельзя одновременно назначить и API, и Ingress.
Для oVirt и аналогичных провайдеров (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization) в интерфейсах создания клиентского кластера и кластера управления дополнительные проверки одновременного заполнения DNS-записи Ingress и VIP-адреса для Ingress не выполняются. Корректность значений можно проверить на шаге проверки конфигурации в режиме dry_run.
Резервирования IP нет; планируйте непересекающиеся подсети и пулы. FQDN: при DNS-записи Ingress — *.<DNS>; при VIP — *.<имя-кластера>.ip-<VIP>.shturval.link.
См. FQDN и VIP, проверка пересечения подсетей при создании кластера.
Шаг 2–3: Конфигурация узлов
Шаблон выбирается на шаге «Основные данные».
Скриншот: Control Plane
| Параметр Control Plane | Описание |
|---|---|
| Количество узлов | Нечётное число, не больше 5. |
| Cores / Sockets / Threads | Вычислительные ресурсы ВМ (значения по умолчанию в UI). |
| Память (МиБ) | По умолчанию 8192. |
| Диск (ГиБ) | По умолчанию 60; локальное хранилище — не менее 60 ГиБ. |
| Клонировать диск при создании ВМ | Да клонирует диски узлов этой группы, Нет создаёт их без клонирования. По умолчанию берёт значение экземпляра провайдера, а если и там По умолчанию — feature gate disk-clone. То же поле задайте у Worker-групп. Подробнее — клонирование диска. |
Для Worker по умолчанию две группы по три узла (default, infra); можно обнулить количество, добавить группы, настроить ручное/автоматическое масштабирование и копирование настроек (как в документации по vSphere).
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane | 1 или 3 узла. | Для production — 3. |
| Worker: default | Пользовательские нагрузки. | Минимум 2. |
| Worker: infra | Мониторинг, логи, Ingress. | 0 или 3 для production. |
Рекомендуемые ресурсы узлов: требования к клиентскому кластеру.
Особенности oVirt
- Профиль VNIC: Сетевой профиль (например,
ovirtmgmt/ovirtmgmt) задаётся в провайдере. В сети должен работать DHCP. - Шаблон: Готовится по единой инструкции.
- CSI: «Разрешить CSI» настраивается в экземпляре провайдера. При включении — oVirt CSI для PersistentVolume.
- Поддерживаемые платформы: oVirt, zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization — настройки идентичны.
API
Метод: POST $BACKENDPOINT/api/v1/platform/providers/clusters/capov
Авторизация: заголовок Authorization: Bearer $token. Получение токена.
Тело запроса: JSON с секциями cluster и provider. В provider используется capovNodeConfig и identityName — имя шаблона провайдера.
Подробнее: API для управления кластерами.
OpenStack и подобные
Предварительные требования
- Настроенный экземпляр провайдера OpenStack;
- Образы (images) для нужных версий Kubernetes;
- VPC, подсети, security groups;
- Возможность настроить внешний балансировщик для KubeAPI/Ingress в облаке (Octavia / Neutron LBaaS и аналоги для VK Cloud, Selectel).
В типовом сценарии пул IP мастера создания кластера не используется — публичные адреса и Ingress выносятся на внешние балансировщики облака.
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для OpenStack / VK Cloud / Selectel:
- Заполните основные данные (базовый или расширенный режим): экземпляр, версию платформы, CSI, при расширенных настройках — внешний LB, DNS Ingress, подсети узлов/подов/сервисов, профиль кластера.
- Настройте Control Plane и Worker (тип ВМ, тип диска, зона доступности, масштабирование групп).
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер. При использовании внешнего балансировщика затем завершите настройку LB в панели виртуализации (Виртуальные сети / балансировщики) (см. скриншот ниже).
Как узлы создаются из образов, см. Создание узлов при развертывании клиентского кластера.
Поля мастера создания кластера
Шаг 1: Основные данные
Заполнение в базовом и расширенном режиме; при переключении в базовый расширенные поля сбрасываются.
Базовый режим
| Поле | Описание |
|---|---|
| Экземпляр | Экземпляр OpenStack (проект, сеть, образы и т.д.); если один — выбирается автоматически. |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы |
| Шаблон ВМ | Какой образ ВМ использовать для всех узлов. Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
| Включить интеграцию CSI | По умолчанию «нет», если в экземпляре нет запрета. |
| Удалить PV при удалении кластера с включенной интеграцией CSI | Да / Нет. По умолчанию Нет. Подробнее: Удаление PV при удалении кластера. |
В базовом режиме расширенная ИБ не включается; FQDN Ingress формируется автоматически:
*.<имя-кластера>.ip-<IP_EXTERNAL_LB>.shturval.link,
где IP_EXTERNAL_LB — VIP внешнего балансировщика Ingress в облаке. Подсети подов и сервисов — по умолчанию. После создания кластера настройте внешний балансировщик в облаке.
Расширенный режим — дополнительно:
| Поле | Описание |
|---|---|
| Использовать внешний балансировщик для Ingress | По умолчанию «да» для этого сценария. |
| DNS-запись Ingress | Wildcard FQDN; итоговые имена — *.<DNS-запись-Ingress>. Если поле пустое, действует автоматическая схема с IP_EXTERNAL_LB, как выше. DNS-запись Ingress ограничена 53 символами, чтобы итоговый commonName для cert-manager не превышал допустимую длину. |
| Установить расширенные параметры информационной безопасности | Secret Encryption для etcd, TLS-соединение с Kubelet и политика аудита. |
| Подсеть подов / подсеть сервисов | CIDR; типично 172.16.0.0/16 и 10.96.0.0/12. |
| Подсеть узлов | Не должна пересекаться с подсетями подов и сервисов; если не задана — берётся из конфигурации провайдера OpenStack. |
| Профиль кластера | См. Профили кластеров. |
Проверка пересечений: проверка пересечения подсетей при создании кластера.
Шаг 2–3: Конфигурация узлов
Образы и типовые параметры ВМ задаются в экземпляре/шаблонах провайдера; на этом шаге — число узлов, тип ВМ, тип диска, объём диска, зона доступности (Control Plane), масштабирование и ресурсы Worker-групп.
Скриншот: Control Plane
Скриншот: Worker-группы
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane | Нечётное число узлов (до 5). | Для production — 3. |
| Worker: default | Пользовательские нагрузки. | Минимум 2. |
| Worker: infra | Системные сервисы. | 0 или 3 для production. |
Рекомендуемые ресурсы: требования к клиентскому кластеру.
Особенности OpenStack
- Сеть и балансировка: В типовом сценарии OpenStack/VK Cloud/Selectel Ingress и публичные endpoint’ы завязаны на внешний балансировщик облака; после создания кластера завершите настройку LB в панели виртуализации.
- Внешний балансировщик: После создания кластера настройте Load Balancer в OpenStack (Neutron LBaaS, Octavia): frontend для
CLUSTERNAME-ingress-backend, порт 30443. - Образы: Готовятся по инструкции платформы. Для Yandex Cloud при создании шаблона используйте флаг
--keep-cloud-init. - Security groups: Должны разрешать трафик для Kubernetes (API, etcd, NodePort и др.).
API
Метод: POST $BACKENDPOINT/api/v1/platform/providers/clusters/capos
Авторизация: заголовок Authorization: Bearer $token. Получение токена.
Тело запроса: JSON с секциями cluster и provider. В provider используется caposNodeConfig и параметры образа.
Подробнее: API для управления кластерами.
Yandex Cloud
Предварительные требования
- Настроенный экземпляр провайдера Yandex Cloud;
- Образы для нужных версий Kubernetes (с флагом
--keep-cloud-initпри создании шаблона утилитой stc); - VPC, подсети, security groups.
KubeAPI и Ingress обычно выносятся на внешние балансировщики Yandex Cloud; отдельный пул IP мастера создания кластера, как у VMware/oVirt, может не использоваться.
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для Yandex Cloud:
- Заполните основные данные (базовый или расширенный режим): экземпляр, версию платформы, при необходимости DNS Ingress, ИБ, CIDR подов/сервисов, профиль кластера.
- Настройте Control Plane и Worker: тип платформы (размер ВМ), тип диска, CPU/RAM/диск, масштабирование групп, роли узлов.
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер (см. скриншот ниже).
Конфигурация экземпляра провайдера, см. иллюстрацию ниже.
Поля мастера создания кластера
Шаг 1: Основные данные
Базовый и расширенный режим (тумблер «Показать расширенные настройки»); при переходе в базовый расширенные значения сбрасываются.
| Поле | Зачем нужно |
|---|---|
| Экземпляр | Настроенный экземпляр провайдера Yandex Cloud. |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы |
| Шаблон ВМ | Какой образ ВМ использовать для всех узлов. Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
| Включить интеграцию CSI | Ставит shturval-capy-csi и подключает диски Yandex Cloud как PersistentVolume. По умолчанию выключена. Управление включением недоступно, если в экземпляре провайдера установка CSI запрещена. |
| Удалить PV при удалении кластера с включенной интеграцией CSI | Да / Нет. Недоступно вместе с интеграцией CSI, если установка CSI в экземпляре запрещена. Подробнее: Удаление PV при удалении кластера. |
Скриншот: основные данные, базовый режим
Базовый режим: помимо имени и экземпляра — версия платформы (совместимая с Kubernetes в шаблонах ВМ экземпляра и текущей платформой; может подставляться автоматически). Расширенная ИБ не включается; DNS-запись Ingress по умолчанию cluster.shturval.link (в базовом режиме не редактируется); CIDR подов и сервисов — по умолчанию.
Скриншот: расширенные основные данные
Расширенный режим
| Поле | Описание |
|---|---|
| DNS-запись Ingress | Wildcard FQDN; итоговые имена *.<DNS-запись-Ingress>. DNS-запись Ingress ограничена 53 символами, чтобы итоговый commonName для cert-manager не превышал допустимую длину. |
| Установить расширенные параметры информационной безопасности | Secret Encryption, TLS-соединение с Kubelet и политика аудита. |
| Подсеть подов / подсеть сервисов | Не должны пересекаться с сетью узлов и друг с другом; см. проверку пересечения подсетей. |
| Профиль кластера | Профили кластеров. |
Адреса KubeAPI и Ingress в облаке задаются через внешние балансировщики Yandex Cloud после появления ресурсов кластера (см. FQDN и VIP).
Шаг 2–3: Конфигурация узлов
Скриншот: Control Plane
| Параметр Control Plane | Описание |
|---|---|
| Число узлов | Нечётное значение. |
| Тип платформы | Профиль ВМ из экземпляра. |
| Тип диска | Из доступных в экземпляре. |
| Диск | По умолчанию 60 ГиБ (минимум для локального хранилища); для production рекомендуется больше. |
| CPU / память | В единицах Gi или Mi; в UI действуют ограничения на минимум. |
Скриншот: Worker-группы
По умолчанию две группы (default, infra) по три узла; доступны ручное/автоматическое масштабирование (минимальное число реплик в GUI обычно не ниже 2), копирование и дублирование групп. В параметрах группы: тип платформы, диск, CPU, память, роли (через запятую; на узлах появятся лейблы node-role.kubernetes.io/...).
Скриншот: редактирование группы Worker
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane | 1 или 3 узла. | Для production — 3. |
| Worker: группа default | Узлы для приложений пользователей. | Минимум 2. |
| Worker: группа infra | Узлы для системных сервисов: мониторинг, логирование, Ingress. Разделение снижает конкуренцию за ресурсы с приложениями. | 0 или 3 для production. |
Рекомендуемые ресурсы: требования к клиентскому кластеру.
Особенности Yandex Cloud
- Пул IP: Не используется. Адреса задаются через внешние балансировщики Yandex Cloud.
- Образы: При создании шаблона утилитой stc обязательно используйте флаг
--keep-cloud-init. - VPC: Подсети подов и сервисов не должны пересекаться с подсетями VPC и другими кластерами.
Подробнее о типичных ошибках и проверках — проверка пересечения подсетей при создании кластера.
API
Метод: POST $BACKENDPOINT/api/v1/platform/providers/clusters/capyc
Авторизация: заголовок Authorization: Bearer $token. Получение токена.
Тело запроса: JSON с секциями cluster и provider. В provider используется capycNodeConfig и параметры образа.
Подробнее: API для управления кластерами.
VMware vCloud Director
Предварительные требования
- Настроенный экземпляр провайдера vCloud Director;
- Каталоги, шаблоны в организации vCloud Director;
- Пул IP-адресов.
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее в мастере для vCloud Director:
- Заполните основные данные (базовый или расширенный режим): экземпляр, шаблон провайдера, версию платформы, DNS Ingress при необходимости, CSI, подсети VIP, pod/service, профиль кластера.
- Настройте Control Plane и Worker (SizingPolicy, DiskSize, масштабирование, роли).
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер. При автоматической схеме имён после создания настройте внешний балансировщик в vCD для Ingress (см. формулу FQDN ниже) (см. скриншот ниже).
Поля мастера создания кластера
Шаг 1: Основные данные
| Поле | Зачем нужно |
|---|---|
| Экземпляр | Экземпляр с настроенным vCloud Director (организация, каталог). |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы |
Базовый режим: помимо имени и экземпляра — шаблон провайдера, версия платформы и при необходимости CSI. Расширенная ИБ не включается. FQDN Ingress по умолчанию:
*.<имя-кластера>.ip-<IP_EXTERNAL_LB>.shturval.link,
где IP_EXTERNAL_LB — VIP внешнего балансировщика Ingress в vCloud Director. Подсети подов и сервисов — значения по умолчанию.
Расширенный режим (тумблер «Показать расширенные настройки»):
Скриншот: расширенные основные данные
| Поле | Описание |
|---|---|
| DNS-запись Ingress | Wildcard FQDN → *.<DNS>; если пусто, действует автоматическая формула с IP_EXTERNAL_LB. DNS-запись Ingress ограничена 53 символами, чтобы итоговый commonName для cert-manager не превышал допустимую длину. |
| Шаблон провайдера | Один шаблон выбирается автоматически при единственном варианте. |
| Шаблон ВМ | Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
| Включить интеграцию CSI | Включает vCloud Director CSI для Persistent Volumes. По умолчанию — нет. Недоступен, если в экземпляре провайдера установка CSI не разрешена. |
| Удалить PV при удалении кластера с включенной интеграцией CSI | Да / Нет. По умолчанию Нет. Подробнее: Удаление PV при удалении кластера. |
| Установить расширенные параметры информационной безопасности | Secret Encryption, TLS-соединение с Kubelet и политика аудита. |
| Подсеть подов / подсеть сервисов | CIDR; проверьте пересечения — проверка пересечения подсетей. |
| Включить интеграцию CSI | Если не запрещено шаблоном; права в vCenter — см. vSphere. |
| kubeAPIVIPSubnet | Подсеть, из которой выбирается IP для KubeAPI. |
| serviceVIPSubnet | Подсеть для сервисов с типом LoadBalancer. |
| Профиль кластера | Профили кластеров. |
Если пул IP не привязан, адреса для управляющего доступа к кластеру и Ingress задайте вручную с учётом подсетей узлов.
Шаг 2–3: Конфигурация узлов
Шаблон задаётся на шаге «Основные данные».
Скриншот: Control Plane
| Параметр Control Plane | Описание |
|---|---|
| Число узлов | Нечётное значение. |
| DiskSize | Объём диска (Gi или Mi); по умолчанию 60 ГиБ, не ниже минимума в UI. |
| SizingPolicy | Политика CPU/RAM из списка vCD. |
Скриншот: Worker-группы
По умолчанию группы default и infra; ручное/автоматическое масштабирование, DiskSize, SizingPolicy, роли (через запятую, лейблы node-role.kubernetes.io/...).
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane | 1 или 3 узла. | Для production — 3. |
| Worker: группа default | Узлы для приложений пользователей. | Минимум 2. |
| Worker: группа infra | Узлы для системных сервисов: мониторинг, логирование, Ingress. Разделение снижает конкуренцию за ресурсы с приложениями. | 0 или 3 для production. |
Рекомендуемые ресурсы: требования к клиентскому кластеру.
Особенности vCloud Director
- Каталоги: ВМ создаются в каталогах организации vCloud Director.
- Шаблоны: Готовятся по единой инструкции.
- CSI: «Разрешить CSI» настраивается в экземпляре провайдера. Если установка разрешена, на шаге «Основные данные» можно включить интеграцию vCloud Director CSI.
- Сеть: В выбранной сети должен работать DHCP.
API
Метод: POST $BACKENDPOINT/api/v1/platform/providers/clusters/capcd
Авторизация: заголовок Authorization: Bearer $token. Получение токена.
Тело запроса: JSON с секциями cluster и provider. В provider используется конфигурация для vCloud Director.
Подробнее: API для управления кластерами.
Basis Dynamix
Предварительные требования
- Настроенный экземпляр провайдера Basis Dynamix;
- Шаблоны или образы для развёртывания узлов.
Пул IP мастера, как у vSphere/oVirt, обычно не используется — Ingress настраивается через внешний балансировщик в Basis Dynamix после создания кластера.
Процесс в GUI
Переход к мастеру и выбор провайдера с экземпляром описаны в начале страницы. Далее для Basis Dynamix:
- Заполните основные данные (базовый или расширенный режим): экземпляр, версию платформы, внешний LB, DNS Ingress, ИБ, CIDR подов/сервисов, профиль кластера.
- Настройте Control Plane и Worker (CPU, RAM, диск, масштабирование).
- Пройдите установку сертификата, выбор сервисов, проверку данных и создайте кластер. В панели Basis Dynamix добавьте frontend балансировщика для
CLUSTERNAME-ingress-backend, порт 30443 (см. ниже).
Скриншот: основные данные мастера
Поля мастера создания кластера
Шаг 1: Основные данные
Базовый и расширенный режим; при переключении в базовый расширенные поля сбрасываются.
Базовый режим
| Поле | Описание |
|---|---|
| Экземпляр | При одном экземпляре выбирается автоматически. |
| Версия платформы | Версия платформы «Штурвал», с которой будет установлен кластер |
| Версия Kubernetes | Версия Kubernetes в соответсвии с выбранной версией платформы |
| Шаблон ВМ | Какой образ ВМ использовать для всех узлов. Появляется после выбора версии платформы, только если в экземпляре несколько шаблонов на одну версию Kubernetes. Подробнее: Выбор шаблона ВМ. |
Расширенная ИБ не включается; CIDR подов и сервисов — по умолчанию. IP Ingress получите после создания: в Сеть → Балансировщики → вкладка Schema → frontend для CLUSTERNAME-ingress-backend, порт 30443.
Расширенный режим
| Поле | Описание |
|---|---|
| Внешний балансировщик для Ingress | После создания кластера настройте LB и frontend, как в базовом режиме. |
| DNS-запись Ingress | Wildcard FQDN → *.<DNS-запись-Ingress>. DNS-запись Ingress ограничена 53 символами, чтобы итоговый commonName для cert-manager не превышал допустимую длину. |
| Установить расширенные параметры информационной безопасности | Secret Encryption, TLS-соединение с Kubelet и политика аудита. |
| Подсеть подов / подсеть сервисов | Рекомендуемые диапазоны 172.16.0.0/16 и 10.96.0.0/12; проверьте пересечения — проверка пересечения подсетей. |
| Профиль кластера | Профили кластеров. |
Шаг 2–3: Конфигурация узлов
Шаблон задаётся в экземпляре и на шаге основных данных мастера.
Скриншот: Control Plane
| Параметр Control Plane | Описание |
|---|---|
| Число узлов | Нечётное, не больше 5. |
| CPU / память / диск | По умолчанию близки к минимальным требованиям; в UI есть нижние пределы. |
Скриншот: Worker-группы
Группы default и infra, ручное/автоматическое масштабирование, копирование настроек. 0 узлов в группе — MachineDeployment без узлов до последующего масштабирования.
Скриншот: параметры Worker
| Параметр | Зачем нужно | Рекомендации |
|---|---|---|
| Control Plane | Нечётное количество. | До 5 узлов. |
| Worker: группа default | Узлы для приложений пользователей. | По умолчанию 3. |
| Worker: группа infra | Узлы для системных сервисов: мониторинг, логирование, Ingress. Разделение снижает конкуренцию за ресурсы с приложениями. | 0 или 3 для production. |
Рекомендуемые ресурсы: требования к клиентскому кластеру.
Особенности Basis Dynamix
- Пул IP: Не используется. Адреса задаются через внешние балансировщики.
- Внешний LB: Обязательно настройте Load Balancer в Basis Dynamix после создания кластера.
- Шаблоны: Готовятся по единой инструкции.
API
Метод: POST $BACKENDPOINT/api/v1/platform/providers/clusters/capbd
Авторизация: заголовок Authorization: Bearer $token. Получение токена.
Тело запроса: JSON с секциями cluster и provider. В provider используется конфигурация для Basis Dynamix.
Подробнее: API для управления кластерами.
Шаги мастера, общие для всех провайдеров
После шагов, специфичных для провайдера (основные данные и узлы), мастер Создать кластер для всех типов инфраструктуры включает установку сертификата, выбор сервисов и проверку данных.
Шаг 5: Установка сертификата
Скриншот шага «Сертификат»
| Вариант | Когда использовать |
|---|---|
| Самоподписной | Тест и внутренние сценарии; браузер покажет предупреждение. Дополнительная настройка не требуется. |
| Промежуточный | Свой промежуточный CA: загрузите цепочку PEM и закрытый ключ (файл или текст). |
| ACME | Внешний ACME-сервер: корневой CA, URL сервера с портом и путём. При сбое ACME-сервера кластеры с таким сертификатом могут стать недоступны — нужен мониторинг. |
| Корпоративный | PEM цепочка и ключ Ingress, выпущенные вашим CA или самоподписанные под домен Ingress. |
| Let’s Encrypt | Email учётной записи; корневой Let’s Encrypt подставляется автоматически; сервер по умолчанию https://acme-v02.api.letsencrypt.org/directory. |
Для первого кластера чаще выбирают самоподписной сертификат.
Сертификат можно сменить после развёртывания (ClusterIssuer, загрузка корпоративного сертификата и т.д.). Установленные при создании кластера issuer’ы доступны в разделе администрирования кластера (ClusterIssuers).
Дополнительные скриншоты по типам сертификата (справочно)
Шаг 6: Выбор сервисов
На шаге доступен выбор, что использовать для управления HTTP-трафиком. Можно выбрать только один вариант.
| Вариант | Описание |
|---|---|
| NGINX Ingress Controller | Выбран по умолчанию. Внешний HTTP-трафик принимает модуль управления внешними подключениями (shturval-ingress-controller). |
| Gateway API | Внешний HTTP-трафик принимает Gateway API на Cilium. Модуль управления внешними подключениями (shturval-ingress-controller) устанавливается в режиме absent. Контроллер Gateway API в Cilium и выпуск сертификатов для Gateway API в cert-manager уже включены. |
Критически важные сервисы всегда включены и недоступны для отключения. К ним относятся сетевые компоненты, VIP, локальное хранилище, сервисы управления и обновления, ключевые CRD (например, shturval-networking, shturval-gateway-api-crds, shturval-ingress-controller, shturval-local-csi, shturval-snapshotter, shturval-node-config, shturval-services, shturval-update, shturval-vip, shturval-vip-provider, shturval-caching-dns, shturval-cert-manager, shturval-trust-manager).
В базовом режиме сервисы выбираются по группам быстрой установки:
| Группа | Описание | Основные сервисы группы (примеры) |
|---|---|---|
| Мониторинг | Сбор, экспорт метрик | shturval-metrics-collector, shturval-cert-expiration |
| Логирование | Локальный сбор и обработка логов | shturval-log-collector |
| Резервное копирование и восстановление | Резервное копирование и работа со snapshot’ами | shturval-backup, shturval-snapshotter |
| Доставка приложений | Непрерывная доставка и продвинутые стратегии развёртывания | shturval-cd, shturval-rollouts |
| Балансировщик нагрузки | Компоненты для переразмещения нагрузок | shturval-descheduler |
| Инструменты ИБ | Анализ конфигураций и сканирование образов | shturval-policy-manager, shturval-scanner |
В режиме расширенных настроек можно выбрать отдельные сервисы. При переключении между базовым и расширенным режимом сделанный на шаге выбор сбрасывается.
Скриншоты: базовый и расширенный выбор сервисов
Если вы включили сервис с зависимостями, платформа автоматически отмечает необходимые зависимые сервисы.
Полный состав групп и перечень чартов см. на странице «Сервисы репозитория Shturval» и в разделе «Установка сервисов в процессе развёртывания кластера».
На шаге мастера рекомендуется включить Мониторинг (Victoria Metrics, Grafana, дашборды) и Логирование (Vector). При необходимости — Резервное копирование и восстановление (Velero), Доставка приложений (Argo CD), Инструменты ИБ (Kyverno, Trivy) или Балансировщик нагрузки (Descheduler). Сервисы из группы Критические сервисы (сети, VIP, локальное хранилище, cert-manager, CRD Gateway API, shturval-services и др.) всегда включены и отключить их нельзя.
Проверка данных и создание
На последнем шаге отображается сводка всех параметров в режиме чтения, в том числе что выбрано для управления HTTP-трафиком и имя выбранного Шаблона ВМ, если поле было на шаге Основные данные. Чтобы исправить значения, перейдите по названию шага в левой панели или нажмите Назад. Доступна проверка конфигурации кластера перед созданием — запуск развертывания кластера в режиме dry_run. После успешной проверки, нажмите Создать кластер, чтобы запустить развёртывание.
При проверке конфигурации создаётся неймспейс с именем кластера. После завершения проверки он удаляется автоматически. Удаление может занять несколько минут — в этом случае при запуске создания кластера в интерфейсе появится предупреждение. Дождитесь полного удаления неймспейса и повторно запустите развёртывание кластера.
Скриншоты: запуск и результаты проверки параметров перед созданием кластера
Как и где запустить проверку, см. иллюстрацию ниже.
Попытка инициировать кластер без проверки, см. иллюстрацию ниже.
Ожидание прохождения проверки, см. иллюстрацию ниже.
Если в результате проверки возникнет ошибка, вы увидите ее в правом верхнем углу экрана, см. иллюстрацию ниже.
Если проверка пройдена успешно, см. иллюстрацию ниже.
Отслеживание статуса развёртывания
Подробное описание блока статуса, этапов, таблиц узлов и сервисов см. Статус развертывания кластера.
- Создание кластера занимает до 60 минут.
- Откройте Кластер → Клиентские кластеры, выберите имя создаваемого кластера; до завершения развёртывания статус также на странице Администрирование → Дашборд (см. Дашборд до завершения развёртывания).
- На дашборде кластера отображается блок «Статус развёртывания кластера» с общим прогрессом и этапами создания ВМ или подготовки хостов, bootstrap, установки Kubernetes, применения NCI и установки сервисов.
- Завершённые этапы объединяются в единый блок готовности. Доступно управление режимом отображения данных этапов.
- Статус сменится на Готов, когда готова инфраструктура и подняты все узлы Control Plane и Worker. Этапы NCI и установки сервисов не влияют на итоговый статус; при раннем переходе в Готов проверьте NCI и сервисы отдельно (см. раздел Клиентский кластер в справочнике по статусу).
- Как платформа получает узлы (шаблоны, образы или хосты Shturval v2), как это связано с Cluster API и пулами VIP, см. Создание узлов при развертывании клиентского кластера и Что происходит под капотом.
Что ожидать по времени:
- Создание ВМ: 5–15 мин
- Установка Kubernetes: 10–20 мин
- Установка сервисов: 5–15 мин
Дополнительно об этапах установки сервисов — в Установка сервисов в процессе развёртывания (в том числе раздел про отслеживание установки).
Что делать при ошибке
- Просмотрите сообщение об ошибке на дашборде кластера (condition, события).
- Проверьте траблшутинг — типичные причины и решения.
- Проверьте пересечение подсетей при создании кластера — если ошибка связана с сетью.
После успешного создания
- Скачайте kubeconfig — стрелка рядом с именем пользователя → Скачать Kubeconfig (выберите созданный кластер).
- Проверьте доступ:
kubectl --kubeconfig=dev-cluster.conf get nodes - Настройте мониторинг и алертинг — см. Контроль состояния кластеров.
- Назначьте права доступа пользователям — Назначение прав доступа.
Справочная информация
| Тема | Страница |
|---|---|
| Статус развертывания | Статус развертывания кластера |
| Создание узлов (шаблоны, образы, хосты, CAPI) | Создание узлов при развертывании клиентского кластера |
| Установка сервисов в мастере | Установка сервисов в процессе развертывания кластера |
| API кластеров | API для управления кластерами |
| Пулы IP | Пулы IP-адресов |
| FQDN и VIP | Особенности FQDN или VIP для KubeAPI и Ingress |
| Пайплайн развёртывания | Что происходит под капотом при развёртывании кластера |
| Развёртывание без GUI | Как развернуть кластер без GUI |
| Внешний etcd | Создать кластер с внешним ETCD |
| Профили кластеров | Что такое профили кластеров и как с ними работать |