Установка

Вводная информация

Перед установкой РОСА Кубис необходимо определить, какая версия лицензии будет использована: enterprise или community edition.

Установка в открытом контуре (т.е. из публичного репозитория) доступна в любой версии лицензии.

Установка в закрытом контуре (нет доступа к сети Интернет на всех узлах и зеркале) и условно-закрытом контуре (нет доступа к сети Интернет на всех узлах, есть на зеркале) доступна только в enterprise-лицензии. В закрытом контуре дополнительно требуется Bundle ‒ tar-архив, который содержит в себе всё необходимое для установки Комплекса, и утилита shturval mirror (stm) для работы с зеркалом. Bundle и утилита передаются заказчику вместе с enterprise-лицензией. Подробнее о подготовке зеркала для установки см. п. Ошибка: источник перекрёстной ссылки не найден.

Для установки Комплекса необходимо ознакомиться со следующими разделами настоящего документа:

  • требования к аппаратному и программному обеспечению (п. 3.1.2);
  • подготовка к установке (п. 3.1.3);
  • процесс установке (п. 3.1.4).

Требования к программным и аппаратным средствам

Требования к аппаратным средствам

Кластер управления должен состоять как минимум из одного Control Plane-узла. Для обеспечения отказоустойчивости кластер управления должен состоять как минимум из трех Control Plane-узлов и трех Worker-узлов. Кластер управления требуется устанавливать на технические средства с конфигурацией, указанной в таблицах ниже.

Конфигурация сети должна отвечать следующим положениям:

  • Для виртуальных IP-адресов ControlPlane всегда используется второй IP-адрес в выделенной подсети.
  • Все узлы кластера имеют доступ к зеркалу (Registry). Клиентский кластер должен состоять как минимум из одного Control Plane-узла и одного Worker-узла. Для обеспечения отказоустойчивости кластер должен состоять как минимум из трех Control Plane-узлов и двух Worker-узлов. Системные требования для клиентского кластера указаны в п. 5.1.4. Количество узлов в кластере определяется требованиями к вычислительным ресурсам прикладного ПО с учетом факторов резервирования и механизмов обновления. Следует о****братить внимание, что в пакете лицензии РОСА Кубис установлен лимит по количеству Worker-узлов и vCPU в Комплексе. В случае превышения лимита на всех экранах графического интерфейса кластера отобразится уведомление. При превышении загрузки на значение более 80% ресурса рекомендуется добавлять дополнительный узел. Метрики хранятся 7 дней, логи ротируются по заполнению.

Минимальные системные требования для кластера управления

При установки кластера на Control Plane-узел устанавливаются только критически важные для работы кластера сервисы репозитория shturval. Сервисы логирования, мониторинга, резервного копирования в таком кластере не устанавливаются (рисунок 4).

Рисунок 4 ‒ Минимальная конфигурация

Важно:

  • Кластер управления, развернутый только на одном Control Plane-узле, не должен быть использован в средах, близких к промышленной эксплуатации.
  • На кластере управления в такой конфигурации можно развернуть до 5 клиентских кластеров.
  • При необходимости после установки можно добавить дополнительные узлы в провайдере Shturval v2, если кластер создан с провайдером Shturval v2, или для кластеров с провайдерами oVirt, vSphere масштабировать узлы в кластере управления для полнофункциональной эксплуатации. В таблицах 5 и 6 приведены системные требования для кластера управления в разных вариантах. Таблица 5 ‒ Минимальные системные требования кластера управления c одним Control Plane-узлом

Таблица 6 ‒ Минимальные системные требования кластера управления с одним Control Plane-узлом и тремя Worker-узлами

Минимальные системные требования для кластера в режиме STAND-ALONE приведены в таблицах 7 и 8.

Кластер управления может быть использован для запуска рабочих нагрузок без необходимости создания клиентских кластеров. Подробнее о STAND-ALONE кластере см. на странице отдельно стоящего кластера (п. 3.2.2).

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

Таблица 7 ‒ Минимальные системные требования для кластера в режиме STAND-ALONE на одном Control Plane-узле

Таблица 8 ‒ Минимальные системные требования для кластера в режиме STAND-ALONE с одним Control Plane-узлом и двумя Worker-узлами

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

Рекомендуемая стандартная конфигурация для кластера управления отображена на рисунке 5.

Рисунок 5 ‒ Стандартная конфигурация

Рекомендуемые системные требования для кластера управления приведены в таблице 9.

Таблица 9 ‒ Рекомендуемые системные требования для кластера управления

Требования к хостам

Хост с зеркалом (при установке в закрытом контуре)

Требования к хосту к зеркалом при установке в закрытом контуре:

  • отключен selinux (permissive или disabled);
  • открыты и свободны порты Nginx (параметры http-port и https-port, по умолчанию ‒ 80 и 443).
  • на хосте не установлен container runtime (среда запуска контейнеров). Зеркало устанавливает свой podman. Работа с другим podman не гарантируется. Работа с docker на данный момент не поддерживается.

Узлы кластера

Требования к узлам кластера:

  • должны разрешать имя хоста с зеркалом по действующему FQDN;
  • отключен selinux (permissive или disabled);
  • недоступные репозитории должны быть отключены или удалены (например, родные репозитории дистрибутива);
  • в системе должны быть установлены пакеты iptables и gnupg;
  • для Linux-пользователя должен быть создан домашний каталог в операционной системе (например, /home/shturval). Этот пользователь должен иметь возможность выполнять sudo без пароля.

Требования к IP-адресам

IP-адреса узлов не должны изменяться в процессе эксплуатации кластера. Чтобы заменить узел кластера, необходимо вывести его из состава кластера, а затем добавить в кластер с новым адресом. Для управления масштабированием узлов кластера см. инструкцию "Управление количеством узлов в кластере".

Требования к Control Plane-узлам

IP-адреса Control Plane-узлов кластера должны принадлежать одному широковещательному сегменту сети передачи данных и одной подсети.

Требования к виртуальным IP-адресам

IP-адреса необходимы для использования в качестве виртуальных адресов для сервера Kube-API и Ingress при отсутствии внешнего балансировщика.

Требования к виртуальным IP-адресам:

  • Для установки одного кластера требуется два виртуальных IP-адреса (VIP-адреса), т. е. они не должны быть настроены на каком-либо узле кластера.
  • Первый VIP-адрес должен принадлежать той же подсети, что и IP-адреса узлов с ролью Control Plane. Он используется для API-сервера кластера.
  • Второй VIP-адрес (для Ingress) должен использоваться на сетевом балансировщике нагрузки.
  • Для кластера управления с одним Control Plane узлом IP-адреса должны назначаться строго по возрастающей последовательности в соответствии с цепочкой: сначала IP-адрес узла, затем VIP-адрес для API-сервера и далее VIP-адрес для Ingress. Примеры IP-адресов кластера управления c одним Control Plane узлом:
  • Корректно:
    IP-адрес узла 11.11.11.2
    VIP-адрес API-сервера 11.11.11.3
    VIP-адрес Ingress 11.11.11.4
    
  • Неверно:
    IP-адрес узла 11.11.11.4
    VIP-адрес API-сервера 11.11.11.2
    VIP-адрес Ingress 11.11.11.3
    

Требования к доступам

ПО может быть развернуто с доступом в сеть Интернет или без доступа к сети Интернет**.**

При развертывании ПО с использованием сети Интернет всем узлам в кластере должен быть предоставлен дост****уп к репозиторию.

Для подключения к указанным ресурсам требуется прямой доступ (использование прокси-серверов не поддерживается).

Сетевые требования для удаленного доступа:

  • OpenSSH-сервис на каждом сервере должен отслеживать входящие подключения на порте TCP 22.
  • На каждом сервере должна быть создана сервисная учетная запись пользователя. Имя сервисной учетной записи должно быть одинаковым для всех узлов кластера.
  • На каждом сервере должна быть настроена аутентификация с использованием публичного ключа. Ключ должен быть одинаковым на всех серверах.
  • В сервисной учетной записи должны быть настроены права на выполнение команды sudo без указания пароля.

Требования к ОС

Требования к операционной системе (ОС) включают:

  • на всех узлах кластера должна использоваться одна и та же версия ядра ОС;
  • на всех узлах кластера должны быть установлены следующие пакеты:
  • openssh-server;
  • пакеты, необходимые для установки openssh-server;
  • пакетный менеджер: yum или apt;
  • пакет sudo для запуска команд с повышенными привилегиями.. Комплекс работает под управлением ОС, приведенных в таблице 10. Таблица 10 ‒ Поддерживаемые версии ОС
  • Перед запуском установки с провайдером Shturval v2 требуется отключить Firewalld на всех хостах.

В качестве аппаратного обеспечения РОСА Кубис требуется использовать физические серверы архитектуры x86 и/или виртуальные серверы под управлением oVirt версии не ниже 4.4 и/или VMware vSphere версии гипервизора не ниже 6.7 update 3.

Требования к балансировщику нагрузки

При использовании внешнего балансировщика сетевой нагрузки предъявляются следующие требования:

  • Балансировку сетевой нагрузки требуется реализовывать только на уровне L4.
  • Сетевой балансировщик должен поддерживать механизм сохранения выбора конечного узла на основании IP-адреса источника.
  • Внешний балансировщик для API-сервера при установке кластера с провайдером Shturval V2 должен быть корректно настроен обязательно до начала установки. Пример настройки внешнего балансировщика нагрузки см. в п. 3.1.3.2.

Требования к сетевым именам

Требования к сетевым именам узлов кластера

Каждый узел кластера должен иметь уникальное сетевое имя. Полностью определенное сетевое имя узла кластера должно быть корректным субдоменом DNS.

Важно* ‒ Сетевое имя узла кластера должно быть валидным DNS именем с длиной не более 63 символов.*

Требования к сетевому имени кластера

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

Пример:

(<cluster_name>.<base_domain>)

Важно* ‒ Сетевое имя узла кластера должно быть валидным DNS именем с длиной не более 63 символов.*

Система доменных имен

К системе доменных имен предъявляются следующие требования:

  • В системе DNS должна быть создана зона.
  • Для каждого узла кластера должны быть созданы записи с типом "A" в единственной доменной зоне.
  • Созданные записи должны соответствовать положениям, изложенным в таблице 11. Таблица 11 ‒ Требования к DNS-записям

где:

  • <base_domain> – DNS-зона организации;
  • <server_cluster_name> – имя кластера управления;
  • <client_cluster_name> – имя клиентского кластера.

Требования к сетевым доступам

Firewall (межсетевые экраны) не должны блокировать сетевые соединения. Это требуется для поддержки взаимодействия между компонентами Комплекса.

Схемы межсетевого взаимодействия приведены на рисунках 6‒16 с описанием в соответствующих таблицах 12‒22.

Shturval v2 с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress и CoreHA для клиентского кластера

Рисунок 6 ‒ Shturval v2 с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress и CoreHA для клиентского кластера

Таблица 12 ‒ Описание к рисунку 6

Shturval v2 с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Рисунок 7 ‒ Shturval v2 с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Таблица 13 ‒ Описание к рисунку 7

Shturval v2 с внутренним балансировщиком для KubeAPI и Ingress

Рисунок 8 ‒ Shturval v2 с внутренним балансировщиком для KubeAPI и Ingress

Таблица 14 ‒ Описание к рисунку 8

Shturval v2 с внешним балансировщиком для KubeAPI и Ingress

Рисунок 9 ‒ Shturval v2 с внешним балансировщиком для KubeAPI и Ingress

Таблица 15 ‒ Описание к рисунку 9

Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и Ingress

Рисунок 10 ‒ Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и Ingress

Таблица 16 ‒ Описание к рисунку

Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Рисунок 11 ‒ Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Таблица 17 ‒ Описание к рисунку 11

Shturval v2 DR-платформа с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Рисунок 12 ‒ Shturval v2 DR-платформа с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Таблица 18 ‒ Описание к рисунку 12

oVirt, vSphere c внутренним балансировщиком для KubeAPI и внешним для Ingress

Рисунок 13 ‒ oVirt, vSphere c внутренним балансировщиком для KubeAPI и внешним для Ingress

Таблица 19 ‒ Описание к рисунку 13

oVirt, vSphere c внутренним балансировщиком для KubeAPI, внешним для Ingress и CoreHA в клиентском кластере

Рисунок 14 ‒ oVirt, vSphere c внутренним балансировщиком для KubeAPI, внешним для Ingress и CoreHA в клиентском кластере

Таблица 20 ‒ Описание к рисунку 14

oVirt, vSphere и внутренним балансировщиком для KubeAPI и Ingress

Рисунок 15 ‒ oVirt, vSphere и внутренним балансировщиком для KubeAPI и Ingress

Таблица 21 ‒ Описание к рисунку 15

OpenStack, Basis Dynamix, Yandex Cloud, vCloud Director с внешним балансировщиком для KubeAPI и Ingress

Рисунок 16 ‒ OpenStack, Basis Dynamix, Yandex Cloud, vCloud Director с внешним балансировщиком для KubeAPI и Ingress

Таблица 22 ‒ Описание к рисунку 16

Требования к локальному хранению

В качестве локального хранилища используется RawFile Provisioner, который не поддерживает zfs. В качестве файловой системы могут быть использованы ext4, btrfs, xfs.

Требования к синхронизации времени

В ОС должны быть те же RTC, что и на физическом сервере или хосте виртуализации. Операционные системы, как правило, используют программы NTP или Chrony для синхронизации времени. Подробнее о настройке NTP, Chrony для поддерживаемых ОС в Комплексе см. п. 3.1.3.1.

Сетевые требования для удаленного доступа

  • OpenSSH-сервис на каждом сервере должен отслеживать входящие подключения на порте TCP 22.
  • На каждом сервере должна быть создана сервисная учетная запись пользователя. Имя сервисной учетной записи должно быть одинаковым для всех узлов кластера.
  • На каждом сервере должна быть настроена аутентификация с использованием публичного ключа. Ключ должен быть одинаковым на всех серверах.
  • В сервисной учетной записи должны быть настроены права на выполнение команды sudo без указания пароля.

Требования к инструментам контейнеризации

Для установки кластера управления на локальной машине, с которой будет запущена утилита shtil, должен быть установлен Docker или Podman.

Подробнее об установке Docker см. в п. 3.1.3.3.

Требования к работе в графическом интерфейсе

Рекомендуемое разрешение монитора для работы ‒ 1498*906.

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

Таблица 23 ‒ Поддерживаемые браузеры

Браузеры, из которых графический интерфейс недоступен:

  • IE;
  • Opera Mini;
  • UC Browser for Android;
  • QQ Browser;
  • Baidu Browser;
  • KaiOS Browser.

Подготовка к установке

Настройка NTP-серверов

Если необходимо выставить время без синхронизации (например, такое встречается на Debian), то следует:

  • Установить время RTC в localtime:
    timedatectl set-local-rtc true
    
  • Установить время RTC в UTC:
    timedatectl set-local-rtc false
    
    Синхронизация времени в различных ОС производится выполнением команд в терминальном режиме:
  • для Astra Linux SE:
    sudo apt-get install ntp
    sudo systemctl start ntp
    sudo systemctl enable ntp
    
  • Для Debian:
    sudo apt-get install ntp
    sudo systemctl start ntp
    sudo systemctl enable ntp
    
  • Для Ubuntu:
    sudo apt-get install ntp
    sudo systemctl start ntp
    sudo systemctl enable ntp
    
  • Для РЕД ОС:
    sudo yum install ntp
    sudo systemctl start ntpd
    sudo systemctl enable ntpd
    
    Если не установлены пакеты yum, можно использовать dnf.
  • Для ROSA:
    sudo dnf install ntp
    sudo systemctl start ntp
    sudo systemctl enable ntp
    
  • Для Alt Linux:
    sudo apt-get install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    
  • Для ОСнова:
    sudo apt-get install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    
  • Для Oracle Linux:
    sudo yum install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    
  • Для RHEL:
    sudo yum install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    
  • Для Rocky Linux:
    sudo yum install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    
  • Для SberLinux:
    sudo yum install chrony
    sudo systemctl start chronyd
    sudo systemctl enable chronyd
    

Пример настройки HAProxy

Рекомендуется ознакомиться с требованиями к внешнему балансировщику сетевой нагрузки в п. 3.1.2.6.

Пример настройки внешнего балансировщика нагрузки:

#---------------------------------------------------------------------
myclustername cluster
#---------------------------------------------------------------------
frontend myclustername-api-server
bind 10.11.12.100:6443
default_backend myclustername-api-server
mode tcp
backend myclustername-api-server
balance source
mode tcp
server master1 10.11.13.1:6443 check
server master2 10.11.13.2:6443 check
server master3 10.11.13.3:6443 check
frontend myclustername-ingress-http
bind 10.11.12.100:80
default_backend myclustername-ingress-http
mode tcp
option tcplog
backend myclustername-ingress-http
balance source
mode tcp
server worker1 10.11.13.4:80 check
server worker2 10.11.13.5:80 check
frontend myclustername-ingress-https
bind 10.11.12.100:443
default_backend myclustername-ingress-https
mode tcp
option tcplog
backend myclustername-ingress-https
balance source
mode tcp
server worker1 10.11.13.4:443 check
server worker2 10.11.13.5:443 check
где
10.11.12.100 IP внешнего балансировщика
10.11.13.1 Control Plane 1
10.11.13.2 Control Plane 2
10.11.13.3 Control Plane 3
10.11.13.4 worker1
10.11.13.5 worker2

Установка Docker

Установка Docker необходима, исходя из требований п. 3.1.2.12.

Установка Docker может быть проведена несколькими способами. В настоящей инструкции приведен пример установки Docker Engine с использованием apt-репозитория. При необходимости можно выбрать другой способ установки в официальной документации.

Для установки Docker Engine с использованием apt-репозитория нужно выполнить следующие действия:

  1. настроить apt-репозиторий Docker с помощью команд (рисунок 17):
Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

Рисунок 17 ‒ Настройка apt-репозитория Docker

Рисунок 17 ‒ Настройка apt-репозитория Docker

  1. установить пакеты командой (рисунок 18):
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Рисунок 18 ‒ Установка пакетов 2. проверить статус установки командой (рисунок 19):

sudo systemctl status docker

Рисунок 19 ‒ Проверка статуса установки

Рисунок 18 ‒ Установка пакетов

Рисунок 19 ‒ Проверка статуса установки

Подготовка зеркала для установки в закрытом и условно-закрытом контурах

Закрытый контур ‒ в процессе установки нет доступа к сети Интернет на всех узлах и зеркале.

Условно-закрытый контур ‒ в процессе установки есть доступ к сети Интернет только на зеркале, на всех узлах отсутствует.

Для установки необходим дистрибутив и лицензия РОСА Кубис. Ссылку на скачивание stm, shtil, bundle, а также номер лицензии заказчику передает менеджер со стороны разработчика.

Важно** ‒ **Доступно только в enterprise-версии.

Работа с зеркалом

Команды выполняются с помощью утилиты stm (shturval mirror), которая входит в состав .bundle. При запуске команд необходимо подставлять свои значения для параметров.

Команда инициализации stm init и все доступные параметры приведены в таблице 24.

Таблица 24 ‒ Перечень команд и параметров

Команды инициализации, обновления зеркала в закрытом контуре приведены в таблице 25 (на зеркале нет сети Интернет).

Таблица 25 ‒ Перечень команд и параметров

Команды инициализации, обновления зеркала в условно-закрытом контуре приведены в таблице 26 (на зеркале есть сеть Интернет).

Таблица 26 ‒ Перечень команд и параметров

Основные команды утилиты stm и все доступные параметры приведены в таблице 27.

Таблица 27 ‒ Основные команды утилиты stm и все доступные параметры

Примеры работы с зеркалом

Команда инициализации зеркала:

stm init --fqdn=mirror.ip-XX-XX-XXX-XX.shturval.link --license=XXXXXXXXXX

Следует обратить внимание**, что **можно использовать команду stm bundle make ‒ в закрытом контуре или stm make ‒ в условно-закрытом, включающую инициализацию зеркала и загрузку пакетов и образов.

Пример команды инициализации зеркала и загрузка пакетов и образов из .bundle**.**

stm bundle make --fqdn=mirror.ip-XX-XX-XXX-XX.shturval.link --license=XXXXXXXXXX

Команда загрузки новых версий из .bundle:

stm bundle load --path=../bundle/shturval-bundle

где в --path вместо ../bundle/shturval-bundle нужно указать путь до нового .bundle. Следует обратить внимание**, что в**ыполнять команду необходимо в директории с текущим зеркалом.

Команда инициализации зеркала и загрузка пакетов и образов из репозитория shturval (на зеркале есть сеть Иинтернет):

stm make --fqdn=mirror.ip-XX-XX-XXX-XX.shturval.link --license=XXXXXXXXXX --version=x.x.x

Команда загрузки пакетов и образов из репозитория shturval (на зеркале есть сеть Интернет):

stm download --version=x.x.x

Инструкцию по доставке обновления в закрытом контуре (условно-закрытом) контуре см. в п. 3.1.3.5.

Команда проверки целостности .bundle:

stm bundle check

Команда основных операций с зеркалом

Запуск зеркала. Команда может потребоваться после остановки зеркала
stm start
Перезапуск
stm restart
Остановка зеркала. Команда может потребоваться при подключении Step-ca к зеркалу
stm stop
Проверка статуса зеркала
stm status
Удаление зеркала
stm uninstall

Работа с сертификатами

В Комплексе есть возможность импортировать свой сертификат на этапе инициализации зеркала (stm init, stm bundle make, stm make), на этапе развертывания nginx для внешнего nexus (stm external nginx) или отдельной командой (stm cert import).

В случае если сертификаты подключаются не во время инициализации зеркала или балансировщика, следует воспользоваться Инструкцией "Как прописать сертификаты в зеркало".

Требования к сертификату
  • Требования к сертификату включают:
  • Для импорта необходимо указать файл с цепочкой сертификатов и ключом.
  • Сертификаты и ключ должны быть в **pem-**формате.
  • Цепочка сертификатов должна содержать CA и сам сертификат.
  • Сертификат должен содержать поле subjectAltName** с FQDN зеркала **(FQDN должен совпадать с указанным параметром --fqdn или со значением в конфигурации зеркала).
  • При подписании CSR необходимо сохранить Extensions (для OpenSSL ‒ ключ -copy_extensions copyall). Чтобы импортировать сертификат в зеркало, следует использовать команды для работы с сертификатом, в которые подставить свои значения параметров. Команды и доступные параметры для работы с сертификатами приведены в таблице 28. Таблица 28 ‒ Команды и доступные параметры для работы с сертификатами
Примеры команд

Команды генерации csr и выпуска сертификата:

Важно ‒ Для корректной работы команд потребуется OpenSSL версии не ниже 3.0.

Выпустить запрос на получение сертификата (csr и ключ будут находиться в каталоге export)
stm cert csr --fqdn=mirror.corpdomain.ru
Выпустить сертификат, используя CSR и свой CA (пример для openssl)
openssl x509 -req -sha512  -in export/csr.pem -days 3650 -CA ca/ca_cert.pem \
-CAkey ca/ca_private_key.pem -CAcreateserial -out export/mirror_cert.pem -copy_extensions copyall
Добавить к полученному сертификату свой CA
cat ca/ca_cert.pem >> export/mirror_cert.pem

Команда импорта сертификата на инициализированное зеркало (выполнение приведет к перезапуску зеркала):

stm cert import --cert-file export/mirror_cert.pem --privkey-file export/privkey.pem

Команда инициализации зеркала с импортом сертификата в зеркало:

stm bundle make --fqdn=mirror.corpdomain.ru --license=XXXXXXXXXX --version=2.10.0 \
--cert-file export/mirror_cert.pem --privkey-file export/privkey.pem

Внешний Nexus

Загрузка образов во внешний Nexus

Чтобы загрузить образы во внешний Nexus, используют команды stm external, в которые необходимо подставить свои значения параметров.

Команды и доступные параметры для загрузки образов во внешний Nexus приведены в таблице 29.

Таблица 29 ‒ Команды и доступные параметры для загрузки образов во внешний Nexus

Примеры команд

Команда генерации конфигурации:

stm external config

Команда загрузки содержимого .bundle во внешний Nexus:

stm external load

Команда развертывания Nginx для проксирования запросов во внешний Nexus с импортом сертификата:

stm external nginx --fqdn=mirror.example.ru --cert-file export/mirror_cert.pem --privkey-file export/privkey.pem
Подготовка внешнего Nexus

Для подготовки внешнего Nexus необходимо:

  1. На Nexus создать требуемые hosted-репозитории:
  • Репозитории, обязательные для всех установок ‒ форматы raw, helm, docker;
  • Docker репозиторий должен иметь коннектор (выделенный порт);
  • Для apt-дистрибутивов обязателен Hosted APT repository, названный в конфигурационном файле "deb_universal";
  • Для apt-репозиториев distribution должен быть main;
  • Для apt репозиториев должна быть сгенерирована пара gpg-ключей. Приватный ключ должен быть использован при создании репозитория, публичный должен быть загружен в корень raw репозитория под именем shturval.gpg;
  • Для yum-дистрибутивов обязателен Hosted APT repository, названый в конфиге "rpm_universal";
  • Для yum-репозитория Repodata Depth должна быть установлена в 0;
  • Также необходим yum- или apt-репозиторий для дистрибутива;
  • Например, для дистрибутива РЕД ОС нужен helm, raw, docker и два yum-репозитория, для дистрибутива Astra Linux ‒ helm, raw, docker и два apt-репозитория. Примечание ‒ Имена репозиториев могут быть любыми. Соответствие имен будет установлено в файле конфигурации.
  1. На хосте, имеющем доступ, сгенерировать пример конфигурации командой:
stm external config
  1. Полученный файл config/external-config-example.yaml нужно скопировать как config/external-config.yaml и заполнить в соответствии со своими данными. Соответствие имен репозиториев заполняется как "ключ: значение", где в значении указываются имена созданных репозиториев (ключи менять не следует). Например, если для raw-репозитория был создан репозиторий с именем raw_repo, в конфигурации запись должна выглядеть так:
bin_public: "raw_repo".

Запуск синхронизации из bundle

Запуск синхронизации из .bundle осуществляется командой:

stm external load

После загрузки будет сгенерирован пример конфигурации Nginx. Его можно использовать для создания собственной конфигурации, для поднятия Nginx на нужном хосте. Модуль развертывания зеркала может развернуть собственный Nginx с требуемой конфигурацией (хост должен соответствовать общим требованиям модуля) командой:

stm external nginx –fqdn=mirror.example.ru

Обновление в закрытом контуре

В закрытых установках (закрытый и условно-закрытый контур) Комплекса доставка обновлений может быть осуществлена одним из способов:

  • С помощью ручной загрузки .bundle новой версии на зеркало. Подготовленный .bundle загружается на файлообменник и доступен для загрузки по ссылке.
  • Обновлением зеркала через pipeline без ручной загрузки .bundle. Для обновления зеркало должно быть инициализировано. Чтобы загрузить .bundle и обновить зеркало в закрытом контуре, нужно выполнить следующие шаги:
  1. Скачать .bundle по ссылке, полученной от команды разработки. На виртуальной машине, где инсталлировано зеркало, создать директорию для обновления, например, newbundle и расположить в ней .bundle с обновлением. Пример:
Создание директории
mkdir newbundle
Переход в директорию
cd newbundle
Перемещение .bundle в директорию newbundle
cp downloads/fgfgfg newbundle/fgfgfg
Разархивирование скачанного .bundle
tar -zxvf fgfgfg

где:

  • вместо downloads/fgfgfg указать путь к расположению загруженного .bundle с обновлением;
  • вместо fgfgfg указать имя .bundle.
  1. Когда .bundle распакован, перейти в директорию, где расположено текущее зеркало и запустить обновление зеркала, выполнив команду stm bundle load, в которую проставить свое значение для параметра. Доступный параметр для загрузки содержимого .bundle в зеркало описан в таблице 30. Таблица 30 ‒ Параметр для загрузки содержимого .bundle в зеркало

Команда загрузки новой версии из .bundle в ранее развернутое зеркало:

Выход и переход в директорию с stm
cd ..
cd shturval-offline
Создание директории
./stm bundle load --path=../newbundle/shturval-bundle

где:

  • вместо ../newbundle/shturval-bundle указать путь до загруженного .bundle с обновлением;
  • вместо shturval-offline ‒ директорию текущего зеркала.
    1. По завершении обновления зеркала выполнить шаги инструкции из п. 3.1.3.5.1.

Перезапуск кастомного ресурса обновления

После обновления зеркала требуется перезапустить кастомный ресурс ShturvalUpdateChannel с именем shturval-update, чтобы новая версия обновления для кластера управления и клиентских кластеров Комплекса стала доступна. Без обновления ресурса shturval-update реконсиляция произойдет в течение 6 часов.

Важно:

  • Перезапуск shturval-update необходимо выполнять в каждом кластере, для которого будет проводится обновление.
  • После перезапуска shturval-update возможность обновить кластер появится через некоторое время (потребуется около 5-10 минут). Можно обновить shturval-update из графического интерфейса или в интерфейсе командной строки.
Из интерфейса командной строки

Для обновления из интерфейса командной строки нужно добавить произвольный лейбл ресурсу shturval-update, который находится в неймспейсе shturval-update-system. После успешного обновления произойдет реконсиляция ресурса и можно перейти к обновлению кластера.

Пример команды добавления лейбла (рисунок 20):

kubectl label ShturvalUpdateChannel shturval-update --namespace shturval-update-system example=

где вместо example указать любой лейбл.

Рисунок 20 ‒ Команда добавления лейбла

Из графического интерфейса

Для обновления из графического интерфейса необходимо:

  1. перейти в графический интерфейс кластера и открыть страницу "Кастомные ресурсы" раздела "Администрирование" **(**рисунок 21);
  2. раскрыть API-группу update.shturval.tech и перейти к ShturvalUpdateChannel (****рисунок 22);
  3. открыть манифест кастомного ресурса shturval-update (рисунок 23);
  4. ничего не изменяя, выполнить проверку и нажать кнопку Сохранить (рисунок 24). По завершении перезапуска кастомного ресурса можно перейти к обновлению кластера (п. 5.3.1).

Рисунок 21 ‒ Кастомные ресурсы

Рисунок 22 ‒ Переход к ShturvalUpdateChannel

Рисунок 23 ‒ Открытие манифеста

Рисунок 24 ‒ Проверка и сохранение манифеста

Сертификаты

Самоподписной

Сертификаты при установке применяются в графическом интерфейсе на этапе создания постоянного кластера управления.

При установки с самоподписным сертификатом ничего устанавливать не надо (рисунок 25).

Рисунок 25 ‒ Cоздание кластера с самоподписным сертификатом

После завершения установки и перехода в графический интерфейс Комплекса в веб-браузере потребуется принять сертификат по ссылке https://shturval.<shturval_cluster_name>.<base_domain>, где:

  • <shturval_cluster_name> ‒ IP-адрес или Ingress вашего кластера управления;
  • <base_domain> ‒ ваша доменная зона или shturval.link (если своя доменная зона не была настроена). Чтобы заменить самоподписные на цепочку сертификатов или ACME после завершения установки, следует воспользуйтесь инструкцией "Промежуточный и ACME сертификаты". Для замены сертификатов после завершения установки следует воспользоваться инструкцией "Сценарий замены сертификата".

Корпоративные сертификаты

Сертификаты при установки устанавливаются в графическом интерфейсе на этапе создания постоянного кластера управления.

Чтобы провести установку с корпоративным сертификатом, необходимо создать сертификат.

Следует обратить внимание, что для корректной работы команд потребуется OpenSSL версии не ниже 3.0.

  1. Создать сертификат:
cat > openssl-san.cnf <<EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=RU
ST=Moscow
L=Moscow
O=My Company
OU=Department
emailAddress=admin@example.com
CN = example.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = *.clustername.corp.domain
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
EOF

где corp.domain ‒ Ingress, с которым устанавливается Комплекс.

  1. Создать запрос на сертификат (CSR) с использованием файла конфигурации openssl-san.cnf:
openssl req -newkey rsa:2048 -sha256 -days 365 -nodes -keyout tls.key -out tls.csr -extensions req_ext -config openssl-san.cnf
  1. Отправить созданный запрос на сертификат (CSR) на подпись у вашего удостоверяющего центра (Certificate Authority, CA). В результате должен быть получен подписанный сертификат в формате PEM, который необходимо переименовать в tls.crt. При установке с корпоративным сертификатом потребуется:
  • Загрузить корпоративный сертификат в формате PEM, содержащий "ваш конечный сертификат → промежуточные сертификаты CA → корневой CA". Сертификат должен быть выпущен центром сертификации (Certificate Authority, CA) (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress.
  • Закрытый ключ корпоративного сертификата Ingress. При установке Комплекса в закрытом контуре при использовании корпоративного зеркала корневой сертификат зеркала должен быть прописан в доверенные на все ВМ и шаблоны. Если необходимо установить корпоративный сертификат в созданный кластер, следует выполнить шаги инструкции "Как добавить в кластер".

Промежуточные сертификаты

Если имеется промежуточный сертификат центра сертификации (Intermediate CA), подписанный вашим корпоративным центром сертификации (Certificate Authority, CA), то его можно использовать для автоматической выдачи сертификатов с помощью Cert-manager.

Сертификаты при установки устанавливаются в графическом интерфейсе на этапе создания постоянного кластера управления.

При установки потребуется:

  1. загрузить цепочку сертификатов в формате PEM (ваш промежуточный сертификат  сертификат корпоративного центра сертификации);
  2. загрузить закрытый ключ промежуточного сертификата центра сертификации CA. Можно задать сертификат и ключ, загрузив файлы или указав данные в текстовом формате. Если необходимо установить промежуточный сертификат в созданный кластер, следует выполнить шаги инструкции "Промежуточный и ACME сертификаты".

Сертификаты ACME

Сертификаты при установки устанавливаются в графическом интерфейсе на этапе создания постоянного кластера управления.

С сертификатом ACME потребуется:

  1. загрузить файл корневого сертификата CA для ACME;
  2. задать адрес ACME-сервера с портом и путем к ресурсу. Можно указать Email, который связан с учетной записью ACME. Важно** **‒ Если в кластере установлен сертификат ACME, необходимо мониторить работу ACME-сервера. В случае сбоя на сервере кластеры с сертификатами ACME будут недоступны. После успешной установки кластера установленные сертификаты будут доступны в разделе "Администрирование" на странице "ClusterIssuers" созданного кластера.

Если необходимо установить сертификаты ACME в развернутом кластере, требуется:

  1. с помощью Let’s Enсrypt-сервера выполнить шаги инструкции "Установка сертификата с помощью Let's Enсrypt";
  2. с ACME-сервером выполнить шаги инструкции "Промежуточный и ACME сертификаты".

Сертификаты Let’s Enсrypt

Сертификаты при установки устанавливаются в графическом интерфейсе на этапе создания постоянного кластера управления.

Для создания сертификатов с помощью Let’s Enсrypt необходимо, чтобы ingress-контроллер был доступен из сети Интернет. Для реализации этого требования должно выполняться хотя бы одно из следующих условий:

  • Внешний балансировщик должен иметь белый (публичный) IP-адрес;
  • Должен быть указан белый (публичный) IP-адрес для IngressVIP. С сертификатом Let’s Encrypt потребуется задать Email, который связан с учетной записью. Корневой сертификат СА для Let’s Encrypt загружается автоматически, адрес Let’s Encrypt сервера задан по умолчанию ‒ https://acme-v02.api.letsencrypt.org/directory. После успешной установки кластера сертификат будет доступен в разделе "Администрирование" на странице "ClusterIssuers". Если необходимо установить сертификат Let’s Encrypt в развернутом кластере, следует выполнит шаги инструкции "Установка сертификата с помощью Let's Enсrypt".

Процесс установки

Начало установки

После выбора лицензии можно провести установку РОСА Кубис. Если лицензии еще нет, следует запросить лицензию CE (через форму на сайте или Telegram-бот) или обратиться за enterprise-лицензией к представителю разработчика.

Для установки Комплекса нужно осуществить следующие шаги:

  1. определить контур установки:
  • Открытый (со всех хостов кластера потребуется доступ по порту 443 до репозитория);
  • Закрытый (только для enterprise**; п**еред запуском установки выполнить подготовку зеркала (п. 3.1.3.4), используя выданный менеджером файл .bundle).
  1. выбрать провайдера инфраструктуры:
  2. при использовании провайдера Shturval v2, подготовить хосты с одной из ОС, указанных в таблице 1:
  • один Control Plane (6/8/80) для минимальной конфигурации;
  • три Control Plane (4/16/100) и три Worker (8/32/300) для отказоустойчивой конфигурации;
  • если установка в закрытом контуре, еще один (2/4/150) для зеркала. 2. При использовании одного из провайдеров: oVirt (zVirt, oVirt, HostVM, РЕД Виртуализация, ROSA Virtualization), vSphere, OpenStack (VK Cloud, Selectel), подготовить шаблон виртуальной машины. При необходимости после установки можно будет добавить хосты в провайдер Shturval v2, если кластер создан с провайдером Shturval v2, или для кластеров с провайдерами oVirt, vSphere, Openstack масштабировать узлы в кластере. Следует проверить, что:
  • SELinux отключен или находится в режиме permissive;
  • время между хостами и рабочей машиной синхронизировано;
  • с хостов удалены недоступные (например, родные) репозитории (потребуется только iptables и gnupg).
  1. создать на каждом хосте пользователя. Этот пользователь должен иметь возможность выполнять sudo без пароля;
  2. можно использовать внешний или внутренний балансировщик KubeAPI и/или Ingress:
  • если используется внешний балансировщик, то для каждого компонента нужен FQDN (п. 3.1.2.8);
  • если не используется внешний балансировщик, то подготовить два непингуемых (свободных) IP-адреса. Они не должны быть настроены на каком-либо из хостов кластера, но должны быть в одной подсети с хостами Control Plane-узлов;
  1. подготовить сертификаты для применения при установке или запустить установку без них, тогда будут установлены самоподписанные сертификаты;
  2. перейти к запуску установки с утилитой shtil. Установку можно провести по одному из вариантов:
  • в графическом интерфейсе;
  • в интерфейсе командной строки (beta-версия). Настройки NTP на узлах кластера при установке недоступны. По умолчанию устанавливается Timezone ‒ Europe/Moscow. При необходимости можно настроить NTP на узлах кластера после установки с помощью ресурса NCI.

Установка в графическом интерфейсе

Установка Комплекса в графическом интерфейсе происходит в 2 этапа:

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

Создание временного кластера

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

На машине, с которой будет запущена установка, должен быть:

  • установлен Docker/Podman;
  • доступ до Registry;
  • доступ root-пользователя к каталогу /tmp/, где создаются файлы временного кластера, для запуска установки. Минимальные системные требования к машине, с которой будет запущен shtil:
  • CPU (vCPU) ‒ 3;
  • Memory (GiB) ‒ 3;
  • Disk (GiB) ‒ 20. Минимальные системные требования к ресурсам определяют количество минимально свободных ресурсов для запуска установки. По умолчанию после запуска установки (./shtil-<номер_версии> create cluster) выполняется проверка наличия свободных ресурсов Необходимо сгенерировать ключевую пару с помощью команды:
    ssh-keygen -t ed25519 -f shturval
    
    Ключевая пара потребуется в графическом интерфейсе на шаге "Конфигурация провайдера". Следует скопировать ключевую пару на каждый хост будущего кластера с помощью команды:
    ssh-copy-id -i shturval.pub ssh-user@IP-адрес-хоста
    
    где вместо "IP-адрес-хоста" прописать IP-адрес хоста будущего кластера. Если хостов будет более одного, нужно выполнить команду для каждого хоста.
Установка временного кластера

Для установки временного кластера нужно:

  1. скачать бинарный файл shtil-<номер_версии> из репозитория; Важно:
  • Можно установить кластер управления только соответствующей версии загруженного shtil.
  • Инструмент для работы с контейнерами (Docker, Podman) должен располагаться в одной из директорий, указанной в переменной PATH, иначе устновка прервется.
  1. сделать бинарный файл исполняемым с помощью команды:
chmod +x ./shtil-<номер_версии>
  1. запустить установку с помощью команды ./shtil-<номер_версии> create cluster, в которую необходимо подставить свои значения параметров из таблицы 31. Таблица 31 ‒ Параметры команды

Установка временного кластера занимает некоторое время. Когда инфраструктура временного кластера будет готова, будет получен логин и пароль администратора Комплекса. Следует сохранить их, т. к. они потребуются для дальнейшей аутентификации в Комплексt. По умолчанию логин и пароль сохраняются в файл user.conf по пути $HOME/.shturval/installer (рисунок 26). При необходимости можно изменить временный пароль администратора для первого входа в интерфейс с помощью инструкции "Как сменить пароль администратора".

Рисунок 26 ‒ Установка и сохранение логина и пароля

Следует обратить внимание, что при запуске shtil на виртуальной машине после получения адреса временного кластера потребуется пробросить порты для back, front и authn.

Пример команды проброса портов:

ssh shturval@IP-АДРЕС-ВИРТУАЛЬНОЙ-МАШИНЫ -L 30080:127.0.0.1:30080 -L 30081:127.0.0.1:30081 -L 30082:127.0.0.1:30082
Примеры команды установки временного кластера

Пример команды для открытого контура:

./shtil-<номер_версии> create cluster --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Пример команды для открытого контура c заданным паролем admin:

./shtil-<номер_версии> create cluster --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" --password="ВВЕДИТЕ-ПАРОЛЬ-ДЛЯ-ADMIN"

Для установки в закрытом контуре необходимо добавить параметр --registry.

Пример команды для закрытого контура:

./shtil-<номер_версии> create cluster --registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Важно ‒ Если registry с самоподписным сертификатом, следует прописать registry в конфигурационном файле с реестрами образов контейнеров и пропустить проверку безопасности при подключении к registry (--insecure=true). По умолчанию для Docker конфигурационный файл расположен по пути /etc/docker/daemon.json, для Podman ‒ /etc/containers/registries.conf.

Пример daemon.json (Docker):

{
"insecure-registries" : ["АДРЕС-ВАШЕГО-REGISTRY"]
}

Пример registries.conf (Podman):

Copied from https://raw.githubusercontent.com/projectatomic/registries/master/registries.fedora
This is a system-wide configuration file used to
keep track of registries for various container backends.
It adheres to TOML format and does not support recursive
lists of registries.
The default location for this configuration file is /etc/containers/registries.conf.
The only valid categories are: 'registries.search', 'registries.insecure',
and 'registries.block'.
[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'registry.access.redhat.com']
If you need to access insecure registries, add the registry's fully-qualified name.
An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = ['АДРЕС-ВАШЕГО-REGISTRY']
If you need to block pull access from a registry, uncomment the section below
and add the registries fully-qualified name.
#
Docker only
[registries.block]
registries = []

Пример команды для закрытого контура без проверки безопасности TLS-соединения:

./shtil-<номер_версии> create cluster --registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" --insecure=true

Создание постоянного кластера управления

Предварительно рекомендуется ознакомиться с перечнем браузеров (п. 3.1.2.13), в которых доступен графический интерфейс Комплекса, и перейти по адресу временного кластера в веб-интерфейсе (http://localhost:30080). При этом будет доступна только возможность создания кластера управления (рисунок 27).

Рисунок 27 ‒ Создание кластера управления

Конфигурация провайдеров будет доступна непосредственно в процессе установки.

Создание постоянного кластера управления доступно с провайдерами:

  • VMware vSphere;
  • oVirt, zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization;
  • Shturval v2;
  • Openstack, VK Cloud, Selectel. Процесс создания постоянного кластера в графическом интерфейсе подробнее описан в разделах создания кластеров с провайдерами. Кнопка Отменить инсталляцию возвращает на экран инициализации создания постоянного кластера управления, сбрасывая все заполненные данные. При обновлении страниц конфигурирования кластера управления заполненные данные не сбрасываются.
После установки

После успешной установки кластера управления временный кластер не будет удален автоматически. При необходимости запуска новой установки кластера управления потребуется предварительно удалить временный. Как удалить временный кластер описано в п. 3.1.5.1. При необходимости удалить Комплекс следует воспользоваться п. 3.1.5.2.

Установка в консоли

В РОСА Кубис реализована возможность установки без использования графического интерфейса.

Следует обратить внимание**, что установка** кластера с утилитой shtil без графического интерфейса находится в стадии бета-тестирования.

Установка Комплекса в**** консоли возможна**** одним из способов:

  • Установка в два этапа: создать временный кластер и перейти к установке постоянного кластера управления.
  • Установка в один этап: одновременно задать параметры создания временного кластера и постоянного кластера в одной команде. В этом случае автоматические после успешной установки временного кластера запустится установка постоянного. Примеры команд приведены в пп. 3.1.4.3.5 и 3.1.4.3.6.

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

На машине, с которой будет запущена установка, должен быть:

  • установлен Docker/Podman;
  • доступ до Registry;
  • доступ root-пользователя до каталога /tmp/, где создаются файлы временного кластера, для запуска установки. Минимальные системные требования к машине, с которой будет запущен shtil:
  • CPU (vCPU) ‒ 3;
  • Memory (GiB) ‒ 3;
  • Disk (GiB) ‒ 20. Минимальные системные требования к ресурсам определяют количество минимально свободных ресурсов для запуска установки. По умолчанию после запуска установки (./shtil-<номер_версии> create cluster) выполняется проверка наличия свободных ресурсов. Если установка с провайдером Shturval v2, нужно сгенерировать ключевую пару с помощью команды:
    ssh-keygen -t ed25519 -f shturval
    
    Ключевую пару потребуется задать в конфигурации провайдера. Необходимо скопировать ее на каждый хост будущего кластера с помощью команды:
    ssh-copy-id -i shturval.pub ssh-user@IP-адрес-хоста
    
    где вместо IP-адрес-хоста прописать IP хоста будущего кластера. Если хостов будет более одного, следует выполнить команду для каждого хоста.

Установка утилиты shtil

Для установки нужно:

  1. cкачать бинарный файл shtil-<номер_версии>; Важно:
  • Возможно инсталлировать кластер управления только соответствующей версии загруженного shtil.
  • Инструмент для работы с контейнерами (Docker, Podman) должен располагаться в одной из директорий, указанной в переменной PATH, иначе установка прервется.
  1. Сделать файл исполняемым с помощью команды:
chmod +x ./shtil-<номер_версии>

Создание временного кластера

Установка временного кластера
  1. Запустить установку с помощью команды ./shtil-<номер_версии> create cluster, в которую необходимо подставить свои значения параметров (таблица 32). Таблица 32 ‒ Параметры команды

Инсталляция временного кластера занимает некоторое время. Когда инфраструктура временного кластера будет готова, будет получен логин и пароль администратора Комплекса. Следует сохранить их, они потребуются для дальнейшей аутентификации в Комплексе. По умолчанию логин и пароль сохраняются в файл user.conf по пути $HOME/.shturval/installer (рисунок 28). При необходимости можно изменить временный пароль администратора для первого входа в интерфейс с помощью инструкции "Как сменить пароль администратора".

Рисунок 28 ‒ Установка и сохранение логина и пароля

Важно ‒ При запуске shtil на виртуальной машине после получения адреса временного кластера потребуется пробросить порты для back, front и authn.

Пример команды проброса портов:

ssh shturval@IP-АДРЕС-ВИРТУАЛЬНОЙ-МАШИНЫ -L 30080:127.0.0.1:30080 -L 30081:127.0.0.1:30081 -L 30082:127.0.0.1:30082
Примеры команды установки временного кластера

Пример команды для открытого контура:

./shtil-<номер_версии> create cluster --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Пример команды для открытого контура c заданным паролем admin:

./shtil-<номер_версии> create cluster --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" --password="ВВЕДИТЕ-ПАРОЛЬ-ДЛЯ-ADMIN"
  • Для установки в закрытом контуре нужно добавить параметр --registry. Пример команды для закрытого контура:
    ./shtil-<номер_версии> create cluster --registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"
    
    Важно ‒ Если registry с самоподписным сертификатом, нужно прописать registry в конфигурационном файле с реестрами образов контейнеров и пропустить проверку безопасности при подключении к registry (--insecure=true). По умолчанию для Docker конфигурационный файл расположен по пути ‒ /etc/docker/daemon.json, Podman ‒ /etc/containers/registries.conf. Пример daemon.json (Docker):
    {
    "insecure-registries" : ["АДРЕС-ВАШЕГО-REGISTRY"]
    }
    
    Пример registries.conf (Podman):
Copied from https://raw.githubusercontent.com/projectatomic/registries/master/registries.fedora
This is a system-wide configuration file used to
keep track of registries for various container backends.
It adheres to TOML format and does not support recursive
lists of registries.
The default location for this configuration file is /etc/containers/registries.conf.
The only valid categories are: 'registries.search', 'registries.insecure',
and 'registries.block'.
[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'registry.access.redhat.com']
If you need to access insecure registries, add the registry's fully-qualified name.
An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = ['АДРЕС-ВАШЕГО-REGISTRY']
If you need to block pull access from a registry, uncomment the section below
and add the registries fully-qualified name.
#
Docker only
[registries.block]
registries = []

Пример команды для закрытого контура без проверки безопасности TLS-соединения:

./shtil-<номер_версии> create cluster --registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" --insecure=true

Создание постоянного кластера управления

Установка постоянного кластера управления возможна, если задать конфигурацию в YAML-манифесте или через флаги командной строки.

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

После завершения установки

После установки будет получено:

  • kubeconfig администратора Комплекса;
  • ссылка для перехода в графический интерфейс Комплекса. Следует использовать логин и пароль администратора омплекса, выданные при установке временного кластера. Важно** **** ‒ Следует сохранить логин, пароль и kubeconfig. Они являются статическими и пригодятся для дальнейшей эксплуатации. Полученные логин, пароль и ссылка применимы для аутентификации в Комплексе в графическом интерфейсе. Важно ‒ **Экземпляр провайдера, с которым установлен кластер управления, не должен использоваться при создании клиентских кластеров.

Конфигурация кластера в YAML-манифесте

Общие шаги конфигурации постоянного кластера:

  1. получить шаблон YAML-манифеста, выполнив команду:
/shtil-<номер_версии> install ТИП-ПРОВАЙДЕРА-ИНФРАСТРУКТУРЫ example

Шаблон включает конфигурацию инфраструктурного провайдера и кластера управления. 2. заполнить шаблон своими данными и сохранить в YAML-файле; 3. запустить команду создания кластера, указав флаг установки с YAML-манифестом:

./shtil-<номер_версии> install ТИП-ПРОВАЙДЕРА-ИНФРАСТРУКТУРЫ --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА

Установка постоянного кластер управления возможна со следующими провайдерами:

  • Shturval v2;
  • oVirt. Шаблоны для oVirt-подобных провайдеров (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization) идентичны, потребуется указать дополнительно только подтип;
  • vSphere;
  • OpenStack, VK Cloud, Selectel.
Установка кластера с провайдером Shturval v2

Команда запроса шаблона манифеста:

./shtil-<номер_версии> install shturvalv2 example

Шаблон YAML-манифеста:

---
Шаблон YAML-манифеста установки Комплекса с провайдером Shturval v2
type: CapsmProviderConfig
name: cluster-management-provider       # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию ‒ cluster-management-provider
[ОБЯЗАТЕЛЬНО] Общие учетные данные для SSH-подключения к хостам
credentials:
SSH:
privateKey:                         # [ОБЯЗАТЕЛЬНО] Путь до приватного ключа пользователя для SSH-подключения
userName:                           # [ОБЯЗАТЕЛЬНО] Имя пользователя для SSH-подключения к указанным хостам
Список хостов для узлов кластера
hosts:
 address:                            # [ОБЯЗАТЕЛЬНО] IP-адрес или FQDN хоста (например, 11.12.13.14)
labelsSelector:                     # [ОБЯЗАТЕЛЬНО] Селектор должен содержать метку роли хоста с ключом `role`. Рекомендуемые роли хостов: controlplane, worker, infra, ingress, other
role: controlplane
credentials: null                   # Значение null означает, что для хоста будут использованы общие SSH-учетные данные
SSH:                              # [НЕОБЯЗАТЕЛЬНО] Переопределение общих SSH-учетных данных для хоста. При переопределении удалите null из поля credentials
userName: admin
privateKey: c2RzZHNk
#ingressCerts:                         # Сертификат кластера. По умолчанию кластер будет инсталлирован с самоподписным сертификатом. Только один из подтипов сертификата может быть выбран
ca:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до цепочки сертификатов (ваш промежуточный сертификат -> сертификат корпоративного центра сертификации) в формате "pem" файла. Должен быть задан в паре с `ca.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа промежуточного сертификата CA. Должен быть задан в паре с `ca.crtPath`
tls:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до корпоративного сертификата("pem" файла), который был выпущен CA (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress. Должен быть задан в паре с `tls.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа корпоративного сертификата Ingress. Должен быть задан в паре с `tls.crtPath`
acme:
rootPath: </some/path>            # [НЕОБЯЗАТЕЛЬНО] Путь до файла корневого сертификата CA для ACME. Должен быть задан в паре с `acme.url`
url: example.com                  # [НЕОБЯЗАТЕЛЬНО] Адрес ACME сервера с портом и путем к ресурсу, например: https://acme.corp.lan:8443/directory. Должен быть задан в паре с `acme.rootPath`
email: user@domain.com            # [НЕОБЯЗАТЕЛЬНО] Email, который должен быть связан с учетной записью Let's Encrypt
---
type: CapsmClusterConfig
Конфигурация кластера управления
cluster:
apiEndpoint:                          # [ОБЯЗАТЕЛЬНО] Адрес API-сервера кластера (IP или FQDN без порта и протокола, например, 192.168.1.100)
clusterName: cluster-management       # [НЕОБЯЗАТЕЛЬНО] Имя создаваемого кластера управления. По умолчанию ‒ cluster-management
enabledServices: []                   # [НЕОБЯЗАТЕЛЬНО] Список включенных сервисов из репозитория shturval. По умолчанию (если не задано) в кластере будут установлены критически важные для работы Комплекса сервисы, а также сервисы мониторинга и логирования. Если установлено minimal: true, значения этого параметра будут проигнорированы
externalKubeAPILB: false              # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для API-сервера. По умолчанию ‒ false
externalingresslb: false              # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для Ingress. По умолчанию ‒ false
ingress: ''                           # [ОБЯЗАТЕЛЬНО, если не задан ingressvip] Wildcard DNS-запись для ingress (например, <cluster_name>.<base_domain>). Чтобы задать DNS-запись для ingress, переопределите значение поля externalingresslb на true
controlPlaneNodesCount: 1             # [НЕОБЯЗАТЕЛЬНО] Количество Control Plane узлов. Должно быть не менее 1. По умолчанию ‒ 1
ingressvip:                           # [ОБЯЗАТЕЛЬНО, если externalingresslb: false] VIP-адрес для Ingress контроллера. Чтобы задать VIP-адрес для ingress, должен быть указан externalingresslb: false
podSubnet: 172.16.0.0/16              # [НЕОБЯЗАТЕЛЬНО] Подсеть подов. По умолчанию ‒ 172.16.0.0/16
secure: false                         # [НЕОБЯЗАТЕЛЬНО] Включить расширенные параметры безопасности. По умолчанию ‒ false
serviceSubnet: 10.96.0.0/12           # [НЕОБЯЗАТЕЛЬНО] Подсеть сервисов. По умолчанию ‒ 10.96.0.0/12
shturvalVersion: <номер_версии>               # [НЕОБЯЗАТЕЛЬНО] Версия Комплекса. Соответствует версии утилиты shtil. Переданное значение будет проигнорировано
minimal: false                        # [НЕОБЯЗАТЕЛЬНО] Определяет инсталляцию кластера управления с минимальным набором сервисов. Если задать true, будут установлены только критически важные для работы Комплекса сервисы. При этом сервисы в enabledServices будут проигнорированы
Конфигурации узлов
По умолчанию конфигурация групп Control Plane и Worker-узлов предзаполнена. Создание дополнительных Worker групп недоступно
#provider:
#
## Конфигурация Control Plane узлов
controlPlaneNodeConfig:
controlPlaneSelector:
matchExpressions: []                             # [НЕОБЯЗАТЕЛЬНО] Совпадающие выражения хостов для группы Control Plane узлов
matchLabels:
role: controlplane                             # [НЕОБЯЗАТЕЛЬНО] Лейбл хостов для узлов группы Control Plane. [Не переопределять] Роль для группы Control Plane узлов, должна быть строго controlplane
nodeConfig:
groupName: control-plane                         # [Не переопределять] Имя группы Control Plane узлов
roles:
 name: node-role.kubernetes.io/control-plane  # [Не переопределять] Роль группы Control Plane узлов
name: cluster-management-provider                  # [НЕОБЯЗАТЕЛЬНО] Должно совпадать с именем экземпляра провайдера. По умолчанию name: cluster-management-provider
#
## Конфигурация Worker-узлов
workerNodeConfigs:
 nodeConfig:
groupName: default                            # [Не переопределять] Имя дефолтной группы Worker-узлов
roles:
 name: node-role.kubernetes.io/workers     # [Не переопределять] Роль группы Worker-узлов
workersCount: 3                                 # [НЕОБЯЗАТЕЛЬНО] Количество узлов в дефолтной Worker группе. По умолчанию ‒ 3
workerSelector:
matchExpressions: []                          # [НЕОБЯЗАТЕЛЬНО] Совпадающие выражения хостов для узлов группы Worker-узлов
matchLabels:                                  # Совпадающие лейблы
role: workers                               # [НЕОБЯЗАТЕЛЬНО] Совпадающий лейбл роли хоста для узлов дефолтной группы Worker-узлов. Рекомендовано и по умолчанию workers

Пример конфигурации в YAML-манифесте:

type: CapsmProviderConfig
name: myprovidername
credentials:
SSH:
privateKey: /home/username/.ssh/id_ed25519
userName: shturval
hosts:
‒ address: 10.11.11.11
labelsSelector:
role: controlplane
credentials: null
‒ address: 10.11.12.12
labelsSelector:
role: workers
credentials: null
---
type: CapsmClusterConfig
cluster:
apiEndpoint: 10.11.12.13
clusterName: myclustername
controlPlaneNodesCount: 1
ingressvip: 10.11.12.14
provider:
controlPlaneNodeConfig:
controlPlaneSelector:
matchExpressions: []
matchLabels:
role: controlplane
nodeConfig:
groupName: control-plane
roles:
‒ name: node-role.kubernetes.io/control-plane
workerNodeConfigs:
‒ nodeConfig:
groupName: default
roles:
‒ name: node-role.kubernetes.io/workers
workersCount: 1
workerSelector:
matchExpressions: []
matchLabels:
role: workers

Пример команды создания постоянного кластера управления:

./shtil-<номер_версии> install shturvalv2 --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА
Установка кластера с провайдером oVirt/zVirt/HostVM/РЕД Виртуализация/ROSA Virtualization

Команда запроса шаблона манифеста:

./shtil-<номер_версии> install ovirt example

Шаблон YAML-манифеста:

---
Шаблон YAML-манифеста установки Комплекса с провайдером oVirt
Конфигурация провайдера
type: CapovProviderConfig
#name: cluster-management-provider # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию ‒ cluster-management-provider
credentials:                                                 # [ОБЯЗАТЕЛЬНО] Учетные данные для подключения к API Engine oVirt
oVirt:
url: <https://ovirt-engine.example.com/ovirt-engine/api> # [ОБЯЗАТЕЛЬНО] URL для подключения к API Engine oVirt. Требуется указать полный адрес Engine провайдера, добавив на конце /ovirt-engine/api
username: <admin@internal>                               # [ОБЯЗАТЕЛЬНО] Имя пользователя для аутентификации в API oVirt
password: <password>                                     # [ОБЯЗАТЕЛЬНО] Пароль для аутентификации в API oVirt
#connection:         # [НЕОБЯЗАТЕЛЬНО] Настройки TLS подключения к API oVirt
#tlsInsecure: true # [НЕОБЯЗАТЕЛЬНО] Отключить проверку TLS сертификата. По умолчанию ‒ true. Установите false для продакшена с валидными сертификатами
#tlsCertPath: ''   # [НЕОБЯЗАТЕЛЬНО] Путь к файлу CA сертификата для проверки TLS. Используется при tlsInsecure: false. Пример: /path/to/ca-bundle.crt
providerConfig:                      # [ОБЯЗАТЕЛЬНО] Конфигурация провайдера oVirt
#subtype: zvirt                    # [НЕОБЯЗАТЕЛЬНО] Подтип ovirt-подобного провайдера. Может быть задано одно из значений: zvirt, hostvm, redvirt, rosavirt
datacenter: <Default>              # [ОБЯЗАТЕЛЬНО] Имя датацентра oVirt, где будут создаваться ВМ
datacenterCluster: <Default>       # [ОБЯЗАТЕЛЬНО] Имя кластера oVirt внутри датацентра
vnicProfile: <ovirtmgmt/ovirtmgmt> # [ОБЯЗАТЕЛЬНО] Имя VNIC профиля oVirt для сетевых интерфейсов ВМ
template: <rocky9-template>        # [ОБЯЗАТЕЛЬНО] Имя шаблона ВМ в выбранном датацентре (базовый образ для узлов кластера)
#csiStorage: ''                    # [НЕОБЯЗАТЕЛЬНО] Имя домена хранения для динамических постоянных томов через CSI драйвер. Оставьте пустым для отключения CSI
#vmType: server                    # [НЕОБЯЗАТЕЛЬНО] Тип ВМ для создаваемых виртуальных машин. По умолчанию ‒ server. Не переопределяйте без специальных требований
#templateNetInterface: eth0        # [НЕОБЯЗАТЕЛЬНО] Имя сетевого интерфейса в шаблоне. По умолчанию ‒ eth0. Не переопределяйте, если шаблон не использует другой интерфейс
ingressCerts:                         # Сертификат кластера. По умолчанию кластер будет инсталлирован с самоподписным сертификатом. Только один из подтипов сертификата может быть выбран
ca:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до цепочки сертификатов (ваш промежуточный сертификат -> сертификат корпоративного центра сертификации) в формате "pem" файла. Должен быть задан в паре с `ca.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа промежуточного сертификата CA. Должен быть задан в паре с `ca.crtPath`
tls:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до корпоративного сертификата("pem" файла), который был выпущен CA (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress. Должен быть задан в паре с `tls.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа корпоративного сертификата Ingress. Должен быть задан в паре с `tls.crtPath`
acme:
rootPath: </some/path>            # [НЕОБЯЗАТЕЛЬНО] Путь до файла корневого сертификата CA для ACME. Должен быть задан в паре с `acme.url`
url: example.com                  # [НЕОБЯЗАТЕЛЬНО] Адрес ACME сервера с портом и путем к ресурсу, например: https://acme.corp.lan:8443/directory. Должен быть задан в паре с `acme.rootPath`
email: user@domain.com            # [НЕОБЯЗАТЕЛЬНО] Email, который должен быть связан с учетной записью Let's Encrypt
---
type: CapovClusterConfig           # Конфигурация кластера управления
cluster:                            # [ОБЯЗАТЕЛЬНО] Конфигурация кластера управления
apiEndpoint: <192.168.1.100>      # [ОБЯЗАТЕЛЬНО] Адрес API-сервера кластера (IP или FQDN)
#clusterName: cluster-management  # [НЕОБЯЗАТЕЛЬНО] Имя создаваемого кластера управления. По умолчанию ‒ cluster-management
#enabledServices: []              # [НЕОБЯЗАТЕЛЬНО] Список включенных сервисов, перечисленных через запятую. По умолчанию (если не задано) в кластере будут установлены критически важные для работы Комплекса сервисы, а также сервисы мониторинга и логирования. Если установлено minimal: true, значения этого параметра будут проигнорированы
#externalingresslb: false         # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для Ingress. По умолчанию ‒ false
#ingress: ''                      # [ОБЯЗАТЕЛЬНО, если не задан ingressvip] Wildcard DNS-запись для ingress (например, <cluster_name>.<base_domain>)
#controlPlaneNodesCount: 1        # [НЕОБЯЗАТЕЛЬНО] Количество Control Plane узлов. Должно быть не менее 1. По умолчанию ‒ 1
ingressvip: <192.168.1.101>       # [НЕОБЯЗАТЕЛЬНО] VIP-адрес для Ingress контроллера. Чтобы задать VIP-адрес для ingress, должен быть указан externalingresslb: false
#podSubnet: 172.16.0.0/16         # [НЕОБЯЗАТЕЛЬНО] CIDR подсети подов. По умолчанию ‒ 172.16.0.0/16
#secure: false                    # [НЕОБЯЗАТЕЛЬНО] Включить расширенные параметры безопасности. По умолчанию ‒ false
#serviceSubnet: 10.96.0.0/12      # [НЕОБЯЗАТЕЛЬНО] CIDR подсети сервисов. По умолчанию ‒ 10.96.0.0/12
#shturvalVersion: <номер_версии>          # [НЕОБЯЗАТЕЛЬНО] Версия Комплекса. Должна соответствовать версии утилиты shtil
#minimal: false                   # [НЕОБЯЗАТЕЛЬНО] Определяет инсталляцию кластера управления с минимальным набором сервисов. Если задать true, будут установлены только критически важные для работы Комплекса сервисы. При этом сервисы в enabledServices будут проигнорированы
#provider:                                             # [НЕОБЯЗАТЕЛЬНО] Конфигурации узлов. По умолчанию конфигурация групп Control Plane и Worker-узлов предзаполнена. Создание дополнительных Worker групп недоступно
#name: cluster-management-provider                   # [НЕОБЯЗАТЕЛЬНО] Должно совпадать с именем экземпляра провайдера. По умолчанию ‒ cluster-management-provider
# Конфигурация Control Plane узлов
#controlPlaneNodeConfig:                             # [НЕОБЯЗАТЕЛЬНО] Конфигурация Control Plane узлов
nodeConfig:
groupName: control-plane                        # [Не переопределять] Имя группы Control Plane узлов
roles:
 name: node-role.kubernetes.io/control-plane # [Не переопределять] Роль группы Control Plane узлов, должна быть строго control-plane
capovNodeConfig:
cpu:
cores: 4                                      # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на Control Plane узел. По умолчанию ‒ 4
sockets: 1                                    # [НЕОБЯЗАТЕЛЬНО] Количество CPU сокетов на Control Plane узел. По умолчанию ‒ 1
threads: 1                                    # [НЕОБЯЗАТЕЛЬНО] Количество потоков CPU на сокет. По умолчанию ‒ 1
memory:
sizeMB: 16000                                 # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на Control Plane узел. По умолчанию ‒ 16000
guaranteedMB: 16000                           # [НЕОБЯЗАТЕЛЬНО] Гарантированная память в МБ. Должна совпадать с sizeMB. По умолчанию ‒ 16000
osDiskSizeGB: 100                               # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на Control Plane узел. По умолчанию ‒ 100
# Конфигурация Worker-узлов
#workerNodeConfigs:                                  # [НЕОБЯЗАТЕЛЬНО] Конфигурация Worker-узлов
 nodeConfig:                                     # [НЕОБЯЗАТЕЛЬНО] Создание дефолтной (default) группы Worker-узлов
groupName: default                            # [Не переопределять] Имя дефолтной группы Worker-узлов
roles:
 name: node-role.kubernetes.io/workers     # [НЕОБЯЗАТЕЛЬНО] Роль группы Worker-узлов
workersCount: 3                                 # [НЕОБЯЗАТЕЛЬНО] Количество узлов в дефолтной Worker группе. По умолчанию ‒ 3
capovNodeConfig:
cpu:
cores: 8                                    # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на Worker-узел. По умолчанию ‒ 8
sockets: 1                                  # [НЕОБЯЗАТЕЛЬНО] Количество CPU сокетов на Worker-узел. По умолчанию ‒ 1
threads: 1                                  # [НЕОБЯЗАТЕЛЬНО] Количество потоков CPU на сокет. По умолчанию ‒ 1
memory:
sizeMB: 32000                               # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на Worker-узел. По умолчанию ‒ 32000
guaranteedMB: 32000                         # [НЕОБЯЗАТЕЛЬНО] Гарантированная память в МБ. Должна совпадать с sizeMB. По умолчанию ‒ 32000
osDiskSizeGB: 300                             # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на Worker-узел. По умолчанию ‒ 300

Пример конфигурации в YAML-манифесте:

type: CapovProviderConfig
credentials:
oVirt:
url: https://rhv-mg.example.su/ovirt-engine/api
username: myname@internal
password: password
connection:
tlsInsecure: true
providerConfig:
subtype: zvirt
datacenter: ND
datacenterCluster: RHV
vnicProfile: LAN_3245
template: my-template-ubuntu734-<номер_версии>
csiStorage: Pure_VM_Store
---
type: CapovClusterConfig
cluster:
apiEndpoint: 11.11.12.12
clusterName: myclustername
controlPlaneNodesCount: 1
ingressvip: 11.11.12.13
provider:
controlPlaneNodeConfig:
nodeConfig:
groupName: control-plane
roles:
‒ name: node-role.kubernetes.io/control-plane
capovNodeConfig:
cpu:
cores: 4
sockets: 1
threads: 1
memory:
sizeMB: 9000
osDiskSizeGB: 60
workerNodeConfigs:
‒ nodeConfig:
groupName: default
roles:
‒ name: node-role.kubernetes.io/workers
workersCount: 2
capovNodeConfig:
cpu:
cores: 8
sockets: 1
threads: 1
memory:
sizeMB: 10000
osDiskSizeGB: 60

Команда создания:

./shtil-<номер_версии> install ovirt --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА
Инсталляция кластера с провайдером vSphere

Команда запроса шаблона манифеста:

./shtil-<номер_версии> install vsphere example

Шаблон YAML-манифеста:

---
Шаблон YAML-манифеста для установки Комплекса с провайдером vSphere
type: CapvsProviderConfig           # Конфигурация провайдера
name: cluster-management-provider # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию ‒ cluster-management-provider
[ОБЯЗАТЕЛЬНО] Учетные данные для подключения к vCenter
credentials:
vSphere:
addressVcenter: <https://vcenter.example.com>  # [ОБЯЗАТЕЛЬНО] IP-адрес или полное доменное имя Engine провайдера
usernameVcenter: <administrator@vsphere.local>     # [ОБЯЗАТЕЛЬНО] Имя пользователя учетной записи для подключения к Engine провайдеру
passwordVcenter: <password>                        # [ОБЯЗАТЕЛЬНО] Пароль учетной записи для подключения к Engine провайдеру
Настройки TLS-соединения для vCenter
connection:
tlsInsecure: true       # [НЕОБЯЗАТЕЛЬНО] Отключить проверку TLS-сертификатов. По умолчанию ‒ true.
tlsCertPath: ''         # [НЕОБЯЗАТЕЛЬНО] Путь к файлу CA-сертификата для проверки TLS. Используется при tlsInsecure: false
# Пример: /path/to/ca-bundle.crt
Конфигурация провайдера vSphere
providerConfig:
datacenter: <Datacenter>          # [ОБЯЗАТЕЛЬНО] Имя datacenter vSphere, где будут создаваться виртуальные машины (например, /MyCloud)
datastore: <datastore1>           # [ОБЯЗАТЕЛЬНО] Datastore в dataсenter Engine провайдера (например, MyCloud-example)
resourcePool: <ResourcePool>      # [ОБЯЗАТЕЛЬНО] Путь к пулу ресурсов для виртуальных машин (например, /Datacenter/host/Cluster/Resources/ResourcePool)
network: <VM Network>             # [ОБЯЗАТЕЛЬНО] Имя сети для сетевых интерфейсов виртуальных машин (например, /Datacenter/network/dvPG-example-3245)
folder: <vm-folder>               # [ОБЯЗАТЕЛЬНО] Путь к папке виртуальных машин в инвентаре vCenter (например, /Datacenter/vm/folder)
template: <rocky9-template>       # [ОБЯЗАТЕЛЬНО] Имя шаблона виртуальной машины в выбранном датацентре (базовый образ для узлов кластера)
cloneMode: linkedClone          # [НЕОБЯЗАТЕЛЬНО] Режим клонирования для создания виртуальных машин. По умолчанию ‒ linkedClone.
# linkedClone быстрее и использует меньше места, fullClone создает независимые виртуальные машины
storagePolicy: ''               # [НЕОБЯЗАТЕЛЬНО] Имя политики хранения для дисков виртуальных машин. Оставьте пустым для использования настроек хранилища по умолчанию
enableCSI: true                 # [НЕОБЯЗАТЕЛЬНО] Включить драйвер vSphere CSI для динамических постоянных томов. По умолчанию ‒ true
templateNetInterface: eth0      # [НЕОБЯЗАТЕЛЬНО] Имя сетевого интерфейса в шаблоне. По умолчанию ‒ eth0. Не переопределяйте, если шаблон не использует другой интерфейс
ingressCerts:                         # Сертификат кластера. По умолчанию кластер будет инсталлирован с самоподписным сертификатом. Только один из подтипов сертификата может быть выбран
ca:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до цепочки сертификатов (ваш промежуточный сертификат -> сертификат корпоративного центра сертификации) в формате "pem" файла. Должен быть задан в паре с `ca.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа промежуточного сертификата CA. Должен быть задан в паре с `ca.crtPath`
tls:
crtPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до корпоративного сертификата("pem" файла), который был выпущен CA (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress. Должен быть задан в паре с `tls.keyPath`
keyPath:                          # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа корпоративного сертификата Ingress. Должен быть задан в паре с `tls.crtPath`
acme:
rootPath: </some/path>            # [НЕОБЯЗАТЕЛЬНО] Путь до файла корневого сертификата CA для ACME. Должен быть задан в паре с `acme.url`
url: example.com                  # [НЕОБЯЗАТЕЛЬНО] Адрес ACME сервера с портом и путем к ресурсу, например: https://acme.corp.lan:8443/directory. Должен быть задан в паре с `acme.rootPath`
email: user@domain.com            # [НЕОБЯЗАТЕЛЬНО] Email, который должен быть связан с учетной записью Let's Encrypt
---
type: CapvsClusterConfig            # Конфигурация кластера управления
cluster:
apiEndpoint: <192.168.1.100>      # [ОБЯЗАТЕЛЬНО] Адрес API-сервера кластера (IP или FQDN без порта и протокола, например, 192.168.1.100)
clusterName: cluster-management # [НЕОБЯЗАТЕЛЬНО] Имя создаваемого кластера управления. По умолчанию ‒ cluster-management
enabledServices: []             # [НЕОБЯЗАТЕЛЬНО] Список включенных сервисов, перечисленных через запятую. По умолчанию (если не задано) в кластере будут установлены критически важные для работы Комплекса сервисы, а также сервисы мониторинга и логирования. Если установлено minimal: true, значения этого параметра будут проигнорированы
externalingresslb: false        # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик нагрузки для Ingress. По умолчанию ‒ false
ingress: ''                     # [ОБЯЗАТЕЛЬНО, если не задан ingressvip] Wildcard DNS-запись для ingress (например, <cluster_name>.<base_domain>)
controlPlaneNodesCount: 1       # [НЕОБЯЗАТЕЛЬНО] Количество узлов Control Plane. Должно быть не менее 1. По умолчанию ‒ 1
ingressvip: <192.168.1.101>       # [ОБЯЗАТЕЛЬНО, если externalingresslb: false] VIP-адрес для Ingress-контроллера
podSubnet: 172.16.0.0/16        # [НЕОБЯЗАТЕЛЬНО] CIDR подсети для подов. По умолчанию ‒ 172.16.0.0/16
secure: false                   # [НЕОБЯЗАТЕЛЬНО] Включить расширенные настройки безопасности. По умолчанию ‒ false
serviceSubnet: 10.96.0.0/12     # [НЕОБЯЗАТЕЛЬНО] CIDR подсети для сервисов. По умолчанию ‒ 10.96.0.0/12
shturvalVersion: <номер_версии>         # [НЕОБЯЗАТЕЛЬНО] Версия Комплекса. Должна совпадать с версией утилиты shtil
minimal: false                  # [НЕОБЯЗАТЕЛЬНО] Определяет инсталляцию кластера управления с минимальным набором сервисов. Если задать true, будут установлены только критически важные для работы Комплекса сервисы. При этом сервисы в enabledServices будут проигнорированы
Конфигурации узлов
По умолчанию конфигурация групп Control Plane и Worker-узлов предзаполнена. Создание дополнительных Worker групп недоступно
provider:
name: cluster-management-provider # [НЕОБЯЗАТЕЛЬНО] Должно соответствовать имени экземпляра провайдера. По умолчанию ‒ cluster-management-provider
Конфигурация узлов Control Plane
controlPlaneNodeConfig:
nodeConfig:
groupName: control-plane      # [Не переопределять] Имя группы узлов Control Plane
roles:
 name: node-role.kubernetes.io/control-plane # [Не переопределять] Роль узлов Control Plane
capvsNodeConfig:
cpu:
cores: 4                    # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на узел Control Plane. По умолчанию ‒ 4
memory:
sizeMB: 16000               # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на узел Control Plane. По умолчанию ‒ 16000
osDiskSizeGB: 100             # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на узел Control Plane. По умолчанию ‒ 100
Конфигурация Worker-узлов
workerNodeConfigs:
Создание дефолтной (default) группы Worker-узлов
 nodeConfig:
groupName: default                            # [Не переопределять] Имя дефолтной группы Worker-узлов
roles:
 name: node-role.kubernetes.io/workers     # [Не переопределять] Роль группы Worker-узлов
workersCount: 3                                 # [НЕОБЯЗАТЕЛЬНО] Количество узлов в дефолтной Worker группе. По умолчанию ‒ 3
capvsNodeConfig:
cpu:
cores: 8                  # [НЕОБЯЗАТЕЛЬНО] Количество ядер CPU на Worker-узел. По умолчанию ‒ 8
memory:
sizeMB: 32000             # [НЕОБЯЗАТЕЛЬНО] Размер памяти в МБ на Worker-узел. По умолчанию ‒ 32000
osDiskSizeGB: 300           # [НЕОБЯЗАТЕЛЬНО] Размер диска ОС в ГБ на Worker-узел. По умолчанию ‒ 300

Команда создания:

./shtil-<номер_версии> install vsphere --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА
Инсталляция кластера с провайдером OpenStack/VK Cloud/Selectel

Команда запроса шаблона манифеста:

./shtil-<номер_версии> install openstack example

Команда запроса шаблона манифеста VK Cloud:

./shtil-<номер_версии> install vkcloud example

Команда запроса шаблона манифеста Selectel:

./shtil-<номер_версии> install selectel example

Шаблон YAML-манифеста:

---
Шаблон YAML-манифеста для установки Комплекса с провайдером OpenStack/VK Cloud/Selectel
type: CaposProviderConfig                               # Конфигурация провайдера
#name: my-openstack-provider                            # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию ‒ cluster-management-provider
cloudName: vkcloud                                      # [ОБЯЗАТЕЛЬНО] Имя облака, напр. 'vkcloud', 'openstack' и т.д.
connection:                                             # [ОБЯЗАТЕЛЬНО] Учётные данные для подключения к OpenStack
authURL: https://openstack.example.com:5000/v3        # [ОБЯЗАТЕЛЬНО] URL-адрес доступа к службе авторизации OpenStack (Keystone). Требуется указание порта, например, http://10.11.111.111:5000
projectID: project-id                                 # [ОБЯЗАТЕЛЬНО] ID проекта OpenStack
projectDomainID: project-domain-id                    # [ОБЯЗАТЕЛЬНО] ID домена проекта OpenStack
tlsInsecure: false                                   # [НЕОБЯЗАТЕЛЬНО] Пропустить проверку TLS-сертификата для API OpenStack
tlsCertPath: /path/to/cert                           # [НЕОБЯЗАТЕЛЬНО] Путь к файлу CA-сертификата в формате PEM для API OpenStack
region: RegionOne                                    # [НЕОБЯЗАТЕЛЬНО] Имя региона OpenStack
interface: public                                    # [НЕОБЯЗАТЕЛЬНО] Интерфейс endpoint OpenStack (напр., public, internal)
identityAPIVersion: "3"                              # [НЕОБЯЗАТЕЛЬНО] Identity API OpenStack. По умолчанию ‒ 3
token:                                               # [НЕОБЯЗАТЕЛЬНО] Токен аутентификации. Не может быть использован одновременно с парой login и password. Доступен только для OpenStack
login: username                                      # [НЕОБЯЗАТЕЛЬНО] Имя сервисной учетной записи с ролями heat_stack_owner, admin. Необходимо задать совместно с –password
password: password                                   # [НЕОБЯЗАТЕЛЬНО] Пароль сервисной учетной записи. Необходимо задать совместно с –login
userDomainName: users                                # [НЕОБЯЗАТЕЛЬНО] Имя домена пользователя. Должен быть задан для OpenStack, VK Cloud
resources:                                              # [ОБЯЗАТЕЛЬНО] Конфигурация провайдера OpenStack
sshKeyName: ssh-key-name                              # [ОБЯЗАТЕЛЬНО] Имя пары SSH-ключей для доступа к ВМ по протоколу SSH
nodeCIDR: 10.0.0.0/24                                 # [ОБЯЗАТЕЛЬНО] Подсеть узлов. Например, 10.0.0.0/24. Не должен пересекаться с подсетью подов (podSubnet) и сервисов (serviceSubnet)
externalNetworkID: external-network-id                # [ОБЯЗАТЕЛЬНО] ID внешней сети для floating IP и внешнего доступа
flavors:                                              # [ОБЯЗАТЕЛЬНО] Список типов ВМ
 flavor-name
volumeTypes:                                          # [ОБЯЗАТЕЛЬНО] Список типов дисков
 volume-type
availabilityZones:                                   # [НЕОБЯЗАТЕЛЬНО] Список зон доступности
 zone
managedSecurityGroups: true                          # [НЕОБЯЗАТЕЛЬНО] Управление группами безопасности. По умолчанию ‒ true
disablePortSecurity: false                           # [НЕОБЯЗАТЕЛЬНО] Отключить port security. По умолчанию ‒ false
dns:                                                 # [НЕОБЯЗАТЕЛЬНО] DNS-серверы
machineImageName: image-name                          # [ОБЯЗАТЕЛЬНО] Имя шаблона виртуальной машины. Версия Kubernetes шаблона ВМ должна соответствовать соответствовать версии Штурвала и shtil
enableCSI:                                           # [НЕОБЯЗАТЕЛЬНО] Включить интеграцию CSI. По умолчанию ‒ false
ingressCerts:                                           # [НЕОБЯЗАТЕЛЬНО] Сертификат кластера. По умолчанию кластер будет инсталлирован с самоподписным сертификатом. Только один из подтипов сертификата может быть выбран
ca:
crtPath:                                           # [НЕОБЯЗАТЕЛЬНО] Путь до цепочки сертификатов (ваш промежуточный сертификат -> сертификат корпоративного центра сертификации) в формате "pem" файла. Должен быть задан в паре с `ca.keyPath`
keyPath:                                           # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа промежуточного сертификата CA. Должен быть задан в паре с `ca.crtPath`
tls:
crtPath:                                           # [НЕОБЯЗАТЕЛЬНО] Путь до корпоративного сертификата("pem" файла), который был выпущен CA (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress. Должен быть задан в паре с `tls.keyPath`
keyPath:                                           # [НЕОБЯЗАТЕЛЬНО] Путь до закрытого ключа корпоративного сертификата Ingress. Должен быть задан в паре с `tls.crtPath`
acme:
rootPath: /some/path                               # [НЕОБЯЗАТЕЛЬНО] Путь до файла корневого сертификата CA для ACME. Должен быть задан в паре с `acme.url`
url: example.com                                   # [НЕОБЯЗАТЕЛЬНО] Адрес ACME сервера с портом и путем к ресурсу, например: https://acme.corp.lan:8443/directory. Должен быть задан в паре с `acme.rootPath`
email: user@domain.com                             # [НЕОБЯЗАТЕЛЬНО] Email, который должен быть связан с учетной записью Let's Encrypt
---
type: CaposClusterConfig                                 # Конфигурация кластера управления
cluster:
clusterName: cluster-name                             # [НЕОБЯЗАТЕЛЬНО] Имя создаваемого кластера управления. По умолчанию ‒ cluster-management
enabledServices: []                                  # [НЕОБЯЗАТЕЛЬНО] Список включенных сервисов, перечисленных через запятую. По умолчанию (если не задано) в кластере будут установлены критически важные для работы Комплекса сервисы, а также сервисы мониторинга и логирования. Если установлено minimal: true, значения этого параметра будут проигнорированы
externalingresslb: false                             # [НЕОБЯЗАТЕЛЬНО] Использовать внешний балансировщик для Ingress. По умолчанию ‒ false
ingress: ''                                          # [НЕОБЯЗАТЕЛЬНО] Wildcard DNS-запись для ingress (например, <cluster_name>.<base_domain>)
controlPlaneNodesCount: 1                            # [НЕОБЯЗАТЕЛЬНО] Количество узлов Control Plane. Не менее 1. По умолчанию ‒ 1
podSubnet: 172.16.0.0/16                             # [НЕОБЯЗАТЕЛЬНО] CIDR подсети Pod. По умолчанию ‒ 172.16.0.0/16
secure: false                                        # [НЕОБЯЗАТЕЛЬНО] Включить расширенные настройки безопасности. По умолчанию ‒ false
serviceSubnet: 10.96.0.0/12                          # [НЕОБЯЗАТЕЛЬНО] CIDR подсети Service. По умолчанию ‒ 10.96.0.0/12
shturvalVersion: <номер_версии>                              # [НЕОБЯЗАТЕЛЬНО] Версия Комплекса. Должна совпадать с версией утилиты shtil
minimal: false                                       # [НЕОБЯЗАТЕЛЬНО] Определяет инсталляцию кластера управления с минимальным набором сервисов. Если задать true, будут установлены только критически важные для работы Комплекса сервисы. При этом сервисы в enabledServices будут проигнорированы
Конфигурации узлов
По умолчанию конфигурация групп Control Plane и Worker-узлов предзаполнена. Создание дополнительных Worker групп недоступно
#provider:
name: my-openstack-provider                          # [НЕОБЯЗАТЕЛЬНО] Имя экземпляра провайдера. По умолчанию ‒ cluster-management-provider
Конфигурация узлов Control Plane
controlPlaneNodeConfig:
nodeConfig:
groupName: control-plane                         # [Не переопределять] Имя группы узлов Control Plane
roles:
 name: control-plane                          # [Не переопределять] Роль узлов Control Plane
caposNodeConfig:
openstackFlavorName: flavor-name                 # [НЕОБЯЗАТЕЛЬНО] Тип виртуальной машины для Control Plane узлов. Если не задано, будет использован первый из списка в flavors конфигурации провайдера
volumeSize: 100                                  # [НЕОБЯЗАТЕЛЬНО] Размер корневого тома в ГБ. По умолчанию ‒ 100
volumeType: volume-type                          # [НЕОБЯЗАТЕЛЬНО] Тип диска Control Plane узлов. Если не задано, будет использован первый из списка в volumeTypes
availabilityZone: zone                           # [НЕОБЯЗАТЕЛЬНО] Зона доступности Control Plane узлов. Если не задано, будет использован первый из списка в availabilityZones
Конфигурация Worker-узлов
workerNodeConfigs:                                   # Создание дефолтной (default) группы Worker-узлов
 nodeConfig:
groupName: default                             # [Не переопределять] Имя дефолтной группы Worker-узлов
roles:
 name: worker                               # [Не переопределять] Роль группы Worker-узлов
workersCount: 3                                  # [НЕОБЯЗАТЕЛЬНО] Количество узлов в дефолтной Worker группе. По умолчанию ‒ 3
caposNodeConfig:
openstackFlavorName: flavor-name               # [НЕОБЯЗАТЕЛЬНО] Тип виртуальной машины для Worker узлов. Если не задано, будет использован первый из списка в flavors конфигурации провайдера
volumeSize: 100                                # [НЕОБЯЗАТЕЛЬНО] Размер корневого тома в ГБ. По умолчанию ‒ 300
volumeType: volume-type                        # [НЕОБЯЗАТЕЛЬНО] Тип диска Worker узлов. Если не задано, будет использован первый из списка в volumeTypes
availabilityZone: zone                         # [НЕОБЯЗАТЕЛЬНО] Зона доступности Worker узлов. Если не задано, будет использован первый из списка в availabilityZones

Пример конфигурации в YAML-манифесте с провайдером VK Cloud:

type: CaposProviderConfig
name: mgmtvk-prov
cloudName: vkcloud
connection:
authURL: https://ex.mail.ru:35357/v3/
projectID: c30c
projectDomainID: 384
tlsInsecure: true
region: RegionOne
interface: public
identityAPIVersion: 3
login: "user@example.ru"
password: "mypassw"
userDomainName: users
resources:
sshKeyName: ssh-rsa
nodeCIDR: 10.0.0.0/24
externalNetworkID: eddd4
flavors:
‒ STD2-8-8
volumeTypes:
‒ ceph-ssd
availabilityZones:
‒ ME1
managedSecurityGroups: true
machineImageName: mymachine-2130
---
type: CaposClusterConfig
cluster:
clusterName: myclustername
externalingresslb: true
controlPlaneNodesCount: 1
provider:
controlPlaneNodeConfig:
nodeConfig:
groupName: control-plane
roles:
‒ name: control-plane
caposNodeConfig:
openstackFlavorName: STD2-8-8
volumeSize: 40
volumeType: ceph-ssd
availabilityZone: ME1
workerNodeConfigs:
‒ nodeConfig:
groupName: default
roles:
‒ name: worker
workersCount: 1
caposNodeConfig:
openstackFlavorName: STD2-8-8
volumeSize: 50
volumeType: ceph-ssd
availabilityZone: ME1
Команда создания OpenStack
./shtil-<номер_версии> install openstack --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА
Команда создания VK Cloud
./shtil-<номер_версии> install vkcloud --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА

Команда создания Selectel:

./shtil-<номер_версии> install selectel --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА
Примеры команды установки Комплекса

Чтобы запустить установку Комплекса одной командой, необходимо задать требуемые параметры создания временного кластера и параметр пути до файла с YAML-манифестом —yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА в команде установки постоянного кластера управления с одним из провайдеров.

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

Пример команды создания Комплекса с провайдером Shturval v2 через YAML-манифест для открытого контура:

./shtil-<номер_версии> install shturvalv2 --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА --bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Пример команды создания Комплекса с провайдером oVirt через YAML-манифест для закрытого контура:

./shtil-<номер_версии> install ovirt --yaml-path=ПУТЬ-ДО-РАСПОЛОЖЕНИЯ-YAML-МАНИФЕСТА --bootstrap-registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" --bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Конфигурация кластера с флагами командной строки

Для установки постоянного кластера управления в консоли нужно запустить команду:

./shtil-<номер_версии> install ТИП-ПРОВАЙДЕРА-ИНФРАСТРУКТУРЫ

в которую необходимо подставить свои значения параметров.

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

  • Shturval v2;
  • oVirt. Для oVirt-подобных провайдеров (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization) параметры идентичны, потребуется указать дополнительно флаг подтипа провайдера;
  • vSphere;
  • OpenStack, VK Cloud, Selectel.
Общие параметры установки

Параметры для применения в командах установки с любым типом провайдера приведены в таблице 33.

Таблица 33 ‒ Общие параметры установки

Примеры команд

Общие параметры для установки постоянного кластера управления вне зависимости от провайдера:

  • Для установки Комплекса одной командой (будет запущена установка временного и постоянного кластеров) в открытом окружении в конец нужной команды добавить —bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" для создания временного кластера.
  • Для установки Комплекса одной командой (будет запущена установка временного и постоянного кластеров) в закрытом окружении в конец нужной команды добавить —bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" и —bootstrap-registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY" для создания временного кластера.
  • Для установки с цепочкой сертификатов (ваш промежуточный сертификат  сертификат корпоративного центра сертификации) в конец нужной команды добавить ключи —ingress-certs-ca-crt-path=ВВЕДИТЕ-ПУТЬ-ДО-ПРОМЕЖУТОЧНОГО-СЕРТИФИКАТА и —ingress-certs-ca-key-path=ВВЕДИТЕ-ПУТЬ-ДО-ЗАКРЫТОГО-КЛЮЧА-ПРОМЕЖУТОЧНОГО-СЕРТИФИКАТА.
  • Для установки с корпоративными сертификатами в конец нужной команды добавить ключи —ingress-certs-tls-crt-path=ВВЕДИТЕ-ПУТЬ-ДО-КОРПОРАТИВНОГО-СЕРТИФИКАТА (pem-файла) и —ingress-certs-tls-key-path=ВВЕДИТЕ-ПУТЬ-ДО-ЗАКРЫТОГО-КЛЮЧА-ПРОМЕЖУТОЧНОГО-СЕРТИФИКАТА.
  • Для установки с ACME-сертификатами в конец нужной команды добавить ключи —ingress-certs-acme-root-path=ВВЕДИТЕ-ПУТЬ-ДО-КОРНЕВОГО-СA-ДЛЯ-ACME и —ingress-certs-acme-url=ВВЕДИТЕ-АДРЕС-ACME-СЕРВЕРА-С-ПОРТОМ-И-ПУТЁМ-К-РЕСУРСУ. Инсталляция кластера с провайдером Shturval v2 Команда установки постоянного кластера управления с провайдером Shturval v2:
    ./shtil-<номер_версии> install shturvalv2
    
    Параметры установки постоянного кластера управления с провайдером Shturval v2 приведены в таблице 34. Таблица 34 ‒ Параметры установки для Shturval v2

Пример команды создания постоянного кластера с самоподписными сертификатами на одном Control Plane-узле с VIP для API-сервера и Ingress:

./shtil-<номер_версии> install shturvalv2 \
--ssh-user=ИМЯ-СОЗДАННОГО-ПОЛЬЗОВАТЕЛЯ \
--path-ssh-private-key=ВВЕДИТЕ-ПУТЬ-ДО-ПРИВАТНОГО-КЛЮЧА \
-c=ВВЕДИТЕ-IP-ХОСТА \
--api-endpoint=ВВЕДИТЕ-IP-ДЛЯ-API-СЕРВЕРА \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--cluster-name=ВВЕДИТЕ-ИМЯ-КЛАСТЕРА \
--provider-name=ВВЕДИТЕ-ИМЯ-ЭКЗЕМПЛЯРА-ПРОВАЙДЕРА \
--minimal=true

Инсталляция кластера с провайдером oVirt/zVirt/HostVM/РЕД Виртуализация/ROSA Virtualization

Команда установки постоянного кластера управления с провайдером oVirt/zVirt/HostVM/РЕД Виртуализация/ROSA Virtualization:

./shtil-<номер_версии> install ovirt

Параметры установки постоянного кластера управления с провайдером oVirt/zVirt/HostVM/РЕД Виртуализация/ROSA Virtualization приведены в таблице 35.

Таблица 35 ‒ Параметры установки для oVirt

Пример команды создания постоянного кластера c провайдером zVirt с самоподписными сертификатами с VIP для API-сервера и внешнем балансировщике для Ingress:

./shtil-<номер_версии> install ovirt \
--api-endpoint=ВВЕДИТЕ-IP-ДЛЯ-API-СЕРВЕРА \
--ingress-default-fqdn=ВВЕДИТЕ-FQDN-ДЛЯ-INGRESS \
--use-external-ingress-lb=true \
--url-provider="ВВЕДИТЕ-URL-API-oVirt" \
--user-provider="ВВЕДИТЕ-ИМЯ-ПОЛЬЗОВАТЕЛЯ-УЗ" \
--password-provider="ВВЕДИТЕ-ПАРОЛЬ-УЗ" \
--datacenter-provider=ВВЕДИТЕ-DATACENTER \
--datacenter-cluster-provider=ВВЕДИТЕ-КЛАСТЕР-В-DATACENTER \
--vnic-profile-provider=ВВЕДИТЕ-ИМЯ-VNIC-ПРОФИЛЯ \
--template=ВВЕДИТЕ-ИМЯ-ШАБЛОНА-ВМ \
--sub-type-provider=zvirt \
--cluster-name=ВВЕДИТЕ-ИМЯ-КЛАСТЕРА \
--provider-name=ВВЕДИТЕ-ИМЯ-ПРОВАЙДЕРА \
--provider-csi-storage=ВВЕДИТЕ-ИМЯ-ХРАНИЛИЩА-CSI \
--control-plane=КОЛИЧЕСТВО-CONTROL-PLANE-УЗЛОВ \
--cores-control-plane=ВВЕДИТЕ-КОЛИЧЕСТВО-ЯДЕР-CPU-ДЛЯ-CONTROL-PLANE \
--sockets-control-plane=ВВЕДИТЕ-КОЛИЧЕСТВО-CPU-СОКЕТОВ-ДЛЯ-CONTROL-PLANE \
--threads-control-plane=ВВЕДИТЕ-КОЛИЧЕСТВО-ПОТОКОВ-CPU-ДЛЯ-CONTROL-PLANE \
--memory-control-plane=ВВЕДИТЕ-ОБЪЕМ-ПАМЯТИ-ДЛЯ-CONTROL-PLANE \
--disk-control-plane=ВВЕДИТЕ-ОБЪЕМ-ДИСКА-ДЛЯ-CONTROL-PLANE \
--workers=ВВЕДИТЕ-КОЛИЧЕСТВО-WORKER-УЗЛОВ \
--cores-workers=ВВЕДИТЕ-КОЛИЧЕСТВО-ЯДЕР-CPU-ДЛЯ-WORKER \
--sockets-workers=ВВЕДИТЕ-КОЛИЧЕСТВО-CPU-СОКЕТОВ-ДЛЯ-WORKER \
--threads-workers=ВВЕДИТЕ-КОЛИЧЕСТВО-ПОТОКОВ-CPU-ДЛЯ-WORKER \
--memory-workers=ВВЕДИТЕ-ОБЪЕМ-ПАМЯТИ-ДЛЯ-WORKER \
--disk-workers=ВВЕДИТЕ-ОБЪЕМ-ДИСКА-ДЛЯ-WORKER

Инсталляция кластера с провайдером vSphere

Команда установки постоянного кластера управления с провайдером vSphere:

./shtil-<номер_версии> install vsphere

Параметры установки постоянного кластера управления с провайдером vSphere приведены в таблице 36.

Таблица 36 ‒ Параметры установки для vSphere

Пример команды создания постоянного кластера c провайдером vSphere с самоподписными сертификатами на одном Control Plane-узле и трех Worker-узлах с VIP для API-сервера и для Ingress:

./shtil-<номер_версии> install vsphere \
--api-endpoint=ВВЕДИТЕ-IP-ДЛЯ-API-СЕРВЕРА \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--address-vcenter="ВВЕДИТЕ-АДРЕС-ДО-VCENTER" \
--user-vcenter="ВВЕДИТЕ-ИМЯ-ПОЛЬЗОВАТЕЛЯ" \
--password-vcenter="ВВЕДИТЕ-ПАРОЛЬ-ПОЛЬЗОВАТЕЛЯ" \
--provider-datacenter=ВВЕДИТЕ-DATACENTER \
--provider-datastore=ВВЕДИТЕ-DATASTORE-В-DATACENTER \
--provider-resource-pool="ResourcePool-В-DATACENTER" \
--provider-network="ВВЕДИТЕ-NETWORK" \
--provider-folder="ПАПКА-В-DATACENTER" \
--template=ВВЕДИТЕ-ИМЯ-ШАБЛОНА-ВМ

Инсталляция кластера с провайдером OpenStack/VK Cloud/Selectel

Команда установки постоянного кластера управления с провайдером OpenStack:

./shtil-<номер_версии> install openstack

Команда установки постоянного кластера управления с провайдером VK Cloud:

./shtil-<номер_версии> install vkcloud

Команда установки постоянного кластера управления с провайдером Selectel^

./shtil-<номер_версии> install selectel

Параметры установки постоянного кластера управления с провайдером OpenStack/VK Cloud/Selectel приведены в таблице 37.

Таблица 37 ‒ Параметры установки для OpenStack/VK Cloud/Selectel

Пример команды создания постоянного кластера c провайдером VK Cloud

./shtil-<номер_версии> install vkcloud \
--url-auth="ВВЕДИТЕ-URL-АДРЕС-С-ПОРТОМ" \
--cloud-name="ВВЕДИТЕ-ИМЯ-ОБЛАКА"
--project-id=ВВЕДИТЕ-ИДЕНТИФИКАТОР-ПРОЕКТА \
--project-domain-id=ВВЕДИТЕ-ИДЕНТИФИКАТОР-ДОМЕНА-ПРОЕКТА \
--user-domain-name=ВВЕДИТЕ-ИМЯ-ДОМЕНА-ПОЛЬЗОВАТЕЛЯ \
--login=ВВЕДИТЕ-ИМЯ-СЕРВИСНОЙ-УЧЕТНОЙ-ЗАПИСИ \
--password="ВВЕДИТЕ-ПАРОЛЬ-СЕРВИСНОЙ-УЧЕТНОЙ-ЗАПИСИ" \
--ssh-key-name=ВВЕДИТЕ-ИМЯ-SSH-КЛЮЧЕВОЙ-ПАРЫ \
--node-cidr=ВВЕДИТЕ-ПОДСЕТЬ-УЗЛОВ \
--external-network-id=ВВЕДИТЕ-ИДЕНТИФИКАТОР-ВНЕШНЕЙ-СЕТИ \
--flavors="ВВЕДИТЕ-ТИПЫ-FLAVOR-РАЗДЕЛЕННЫЕ-ЗАПЯТОЙ" \
--volume-types="ВВЕДИТЕ-ТИПЫ-ДИСКОВ-РАЗДЕЛЕННЫЕ-ЗАПЯТОЙ" \
--machine-image-name="ВВЕДИТЕ-ИМЯ-ШАБЛОНА-ВМ" \
--use-external-ingress-lb=true

Примеры команды установки Комплекса

Чтобы запустить установку Комплекса одной командой, необходимо задать требуемые параметры создания временного кластера команде установки постоянного кластера управления с одним из провайдеров.

Пример команды установки Комплекса c провайдером Shturval v2 в открытом контуре:

./shtil-<номер_версии> install shturvalv2 \
--ssh-user=ИМЯ-СОЗДАННОГО-ПОЛЬЗОВАТЕЛЯ \
--path-ssh-private-key=ВВЕДИТЕ-ПУТЬ-ДО-ПРИВАТНОГО-КЛЮЧА \
-c=ВВЕДИТЕ-IP-ХОСТА \
-w=ВВЕДИТЕ-IP-ХОСТОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛОВ \
--api-endpoint=ВВЕДИТЕ-ВАШ-FQDN \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--use-external-kubeapi-lb=true \
--bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Пример команды установки Комплекса c провайдером Shturval v2 в закрытом контуре:

./shtil-<номер_версии> install shturvalv2 \
--ssh-user=ИМЯ-СОЗДАННОГО-ПОЛЬЗОВАТЕЛЯ \
--path-ssh-private-key=ВВЕДИТЕ-ПУТЬ-ДО-ПРИВАТНОГО-КЛЮЧА \
-c=ВВЕДИТЕ-IP-ХОСТОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛОВ \
-w=ВВЕДИТЕ-IP-ХОСТОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛОВ \
--api-endpoint=ВВЕДИТЕ-ВАШ-FQDN \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--use-external-kubeapi-lb=true \
--bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" \
--bootstrap-registry="ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY"

Пример команды установки Комплекса с провайдером vSphere в открытом окружении:

./shtil-<номер_версии> install vsphere \
--api-endpoint=ВВЕДИТЕ-IP-ДЛЯ-API-СЕРВЕРА \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--address-vcenter="ВВЕДИТЕ-АДРЕС-ДО-VCENTER" \
--user-vcenter="ВВЕДИТЕ-ИМЯ-ПОЛЬЗОВАТЕЛЯ" \
--password-vcenter="ВВЕДИТЕ-ПАРОЛЬ-ПОЛЬЗОВАТЕЛЯ" \
--provider-datacenter=ВВЕДИТЕ-DATACENTER \
--provider-datastore=ВВЕДИТЕ-DATASTORE-В-DATACENTER \
--provider-resource-pool="ResourcePool-В-DATACENTER" \
--provider-network="ВВЕДИТЕ-NETWORK" \
--provider-folder="ПАПКА-В-DATACENTER" \
--template=ВВЕДИТЕ-ИМЯ-ШАБЛОНА-ВМ \
--bootstrap-license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

Деинсталляция

Деинсталляция временного кластера

Установка Комплекса включает создание временного и постоянного кластера управления. После установки Комплекса по умолчанию временный кластер не удаляется. Перед установкой нового Комплекса необходимо деинсталлировать (удалить) временный кластер.

Если утилита shtil не установлена, то нужно:

  1. cкачать бинарный файл по ссылке https://public.shturval.tech/shtil-<номер_версии>;
  2. сделать его исполняемым с помощью команды:
chmod +x ./shtil-<номер_версии>

Для деинсталляции (удаления) временного кластера нужно запустить команду:

./shtil-<номер_версии> cleanup clusters

При необходимости можно проставить свое значение параметра. Доступные параметры команды удаления кластера управления приведены в таблице 38. Таблица 38 ‒ Параметры команды удаления временного кластера управления

Примеры удаления временного кластера управления

Команда удаления без вывода информационного журнала (рисунок 29):

./shtil-<номер_версии> cleanup clusters

Рисунок 29 ‒ Результат команды удаления без вывода информационного журнала

Рисунок 29 ‒ Результат команды удаления без вывода информационного журнала

Команда удаления с выводом информационного журнала:

./shtil-<номер_версии> cleanup clusters -v=3

Деинсталляция Комплекса

Установка Комплекса включает создание временного и постоянного кластера управления. Чтобы установить Комплекс заново, заранее потребуется удалить временный кластер, выполнив действия по инструкции.

При необходимости удаления развернутого Комплексаможно воспользоваться утилитой shtil.

Если утилита shtil не установлена, то нужно:

  1. скачать бинарный файл по ссылке https://public.shturval.tech/shtil-<номер_версии>;
  2. сделать его исполняемым с помощью команды:
chmod +x ./shtil-<номер_версии>

Для удаления Комплеса требуется запустить команду:

./shtil-<номер_версии> delete management

в которую необходимо подставить свои значения доступные параметров (таблица 39). Таблица 39 ‒ Параметры при удалении

Важно**:**

  • Удаление доступно только со статическим kubeconfig постоянного кластера управления, выданном для скачивания по завершении установки. В графическом интерфейсе можно найти его в неймспейсе кластера управления, в secret с именем clustername-kubeconfig.
  • Удаление постоянного кластера управления происходит только с временным кластером (bootstrap), поэтому, если временный кластер был удален или недоступен, в команде ./shtil-<номер_версии> delete management нужно указать лицензию (параметр --license) для поднятия временного кластера в открытом окружении или лицензию и Registry (параметры —license, --registry) в закрытом окружении.
  • Docker-контейнер с временным кластером на локальной машине, с которой запускается удаление, должен работать корректно и не быть приостановленным. Одновременно не может быть поднято два Docker-контейнера.
  • В процессе удаления кластера управления shtil запросит подтверждение удаления; потребуется ввести имя кластера управления.
  • Удалить Комплекс невозможно, если в нем развернуты и работают клиентские кластеры.

Примеры деинсталляции (удаления) кластера управления

Пример команды удаления кластера в открытом окружении (временный кластер существует и kubeconfig расположен по пути по умолчанию):

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА

Пример команды удаления кластера в открытом окружении с увеличенной детализацией логов для отладки (временный кластер существует и kubeconfig расположен по пути по умолчанию):

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА --verbosity=3 --retry=50

Пример команды удаления кластера в открытом окружении (временный кластер существует, kubeconfig расположен не по пути по умолчанию):

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА  --bootstrap-kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ВРЕМЕННОГО-КЛАСТЕРА

Пример команды удаления кластера в открытом окружении (нет временного кластера):

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА  --license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ"

По умолчанию временный кластер будет присутствовать.

Пример команды удаления кластера в закрытом окружении (временный кластер существует, kubeconfig расположен не по пути по умолчанию):

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА  --bootstrap-kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ВРЕМЕННОГО-КЛАСТЕРА --registry=ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY

Важно ‒ Если registry с самоподписным сертификатом, следует прописать registry в конфигурационном файле с реестрами образов контейнеров и пропустить проверку безопасности при подключении к registry (--insecure=true). Для Podman по умолчанию конфигурационный файл расположен по пути /etc/containers/registries.conf, для Docker ‒ /etc/docker/daemon.json.

Пример команды удаления для закрытого контура без проверки безопасности TLS-соединения:

./shtil-<номер_версии> delete management --kubeconfig=ВВЕДИТЕ-ПУТЬ-ДО-KUBECONFIG-ПОСТОЯННОГО-КЛАСТЕРА --registry=ВВЕДИТЕ-АДРЕС-ВАШЕГО-REGISTRY --insecure=true

Пример registries.conf:

Copied from https://raw.githubusercontent.com/projectatomic/registries/master/registries.fedora
This is a system-wide configuration file used to
keep track of registries for various container backends.
It adheres to TOML format and does not support recursive
lists of registries.
The default location for this configuration file is /etc/containers/registries.conf.
The only valid categories are: 'registries.search', 'registries.insecure',
and 'registries.block'.
[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'registry.access.redhat.com']
If you need to access insecure registries, add the registry's fully-qualified name.
An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = ['АДРЕС-ВАШЕГО-REGISTRY']
If you need to block pull access from a registry, uncomment the section below
and add the registries fully-qualified name.
#
Docker only
[registries.block]
registries = []

Пример daemon.json:

{
"insecure-registries" : ["АДРЕС-ВАШЕГО-REGISTRY"]
}