Требования

Инфраструктура, лицензия, зеркало, узлы.

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

Все узлы кластера и машина shtil должны иметь сетевой доступ к зеркалу (обычно TCP 443 или порт, заданный при инициализации зеркала).

Требования к квалификации администратора #

Администратор должен обладать:

• базовыми навыками администрирования Linux;
• навыками работы с Kubernetes и процессами автоматизации управления контейнерными приложениями в кластерах.

Поддерживаемые провайдеры #

• Shturval v2 — bare metal / хосты по SSH
• oVirt (в т.ч. zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization)
• VMware vSphere

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

Подробнее: Как устроена работа с провайдерами.

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

• ОС: Linux. Утилиту stm необходимо запускать на хосте с ОС Linux.
• Ресурсы: минимум 2 vCPU, 4 GiB RAM, 150 GiB диск; рекомендуется 4 vCPU, 16 GiB RAM, 300 GiB диск.
• SELinux: permissive или disabled.
• Порты Nginx (параметры http-port и https-port, по умолчанию 80 и 443): должны быть свободны.
• Container runtime: на хосте не устанавливайте Docker вручную. Используйте Docker из состава бандла; работа с другим экземпляром контейнерного runtime не гарантируется.
• Сертификат: при импорте — PEM (цепочка CA и сертификат), subjectAltName с FQDN зеркала, совпадающим с параметром --fqdn.

Ресурсы хоста зеркала #

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

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

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

Обратите внимание! Внимание: Кластер на одном Control Plane не рекомендуется для production. До 5 клиентских кластеров.

В лицензии заданы лимиты по Worker-узлам и vCPU; при превышении в интерфейсе отображается уведомление.

При загрузке свыше 80% рекомендуется добавлять узлы. Метрики хранятся 7 дней; логи ротируются по заполнению.

Минимальная конфигурация (1 Control Plane узел) #

Только для тестовых инсталляций

Рекомендуемая конфигурация (1 CP + 3 Worker) #

Не рекомендуется для production инсталляций

Отказоустойчивая конфигурация (3 CP + 3 Worker) #

Stand-alone кластер (без клиентских кластеров) #

Для stand-alone в закрытом периметре используйте строку Зеркало из минимальной конфигурации.

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

Ресурсы машины shtil #

Утилиту shtil необходимо запускать с хоста с ОС Linux. Минимум 3 vCPU, 3 GiB RAM, 20 GiB диск; Docker из состава бандла; сетевой доступ к зеркалу по HTTPS (порт по настройке зеркала, обычно 443). Если у зеркала самоподписной или корпоративный CA, настройте доверие к зеркалу на уровне демона Docker до запуска shtil: флаги --bootstrap-insecure и --bootstrap-registry-certs-dir не влияют на первичный docker pull. Проверки — на странице Подготовка.

Поддерживаемые операционные системы машины запуска shtil #

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

Поддерживаемые операционные системы узлов кластера #

На всех узлах кластера должна использоваться одна и та же версия ядра ОС.

Обязательные пакеты на узлах: openssh-server и зависимости, пакетный менеджер (yum или apt), sudo, iptables, gnupg.

Инфраструктура: физические серверы архитектуры x86 и/или виртуальные машины под управлением oVirt версии не ниже 4.4 и/или VMware vSphere (гипервизор не ниже 6.7 update 3).

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

• Узлы должны резолвить FQDN зеркала и другие сетевые имена, используемые выбранным сценарием.
• SELinux — режим permissive или disabled.
• Недоступные репозитории пакетов ОС должны быть отключены или удалены.
• Для Linux-пользователя, от имени которого выполняется установка (например, /home/shturval), должен быть создан домашний каталог.
• Пользователь для установки должен иметь возможность выполнять sudo без пароля на всех целевых узлах.

Удалённый доступ по SSH при инсталляции на предварительно созданных хостах #

На каждом сервере:

1. Служба OpenSSH принимает подключения на порту TCP 22.
2. Создана одинаковая на всех узлах сервисная учётная запись для установки.
3. Настроена аутентификация по одинаковому публичному ключу на всех узлах.
4. Для сервисной учётной записи разрешено выполнение sudo без пароля.

Локальное хранилище #

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

Сетевые требования #

Межсетевые экраны не должны блокировать необходимые соединения.

Основные порты #

* или порт, заданный при развёртывании зеркала.

LDAP и OIDC (Keycloak, Blitz): только внутри закрытого периметра.

S3 (Velero): только внутреннее S3-совместимое хранилище.

Правила адресации и доступа #

1. IP-адреса узлов не меняются в процессе эксплуатации кластера.
2. Машина shtil и все узлы кластера должны иметь доступ к зеркалу по HTTPS (порт по настройке зеркала, обычно 443).
3. Кластер управления должен иметь доступ к API используемых провайдеров инфраструктуры (oVirt Engine, vCenter и т.д. — по сценарию развёртывания).

Подсеть Control Plane и виртуальные IP (VIP) #

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

Если используются внешние балансировщики для KubeAPI и/или Ingress, выделение VIP не требуется. Требования и пример настройки внешнего балансировщика приведены ниже.

Дополнительные правила для внутренних VIP:

1. VIP не должны быть настроены на интерфейсах узлов до установки.
2. VIP для API-сервера должен принадлежать той же подсети, что и IP-адреса узлов Control Plane.
3. VIP для Ingress используется на сетевом балансировщике нагрузки и должен быть доступен с рабочей станции администратора, если выбран сценарий с внутренним Ingress.
4. Для кластера управления с одним Control Plane IP-адреса должны назначаться по возрастанию: сначала IP-адрес узла, затем VIP API-сервера, затем VIP Ingress.

Внешний балансировщик нагрузки #

При развёртывании кластера с несколькими Control Plane узлами для KubeAPI требуется балансировщик нагрузки. Платформа может использовать встроенный (VIP через Kube-VIP) или внешний балансировщик.

Внешний балансировщик также используется для Ingress, когда трафик должен идти через общую точку входа, например HAProxy перед кластером.

Требования:

1. Балансировка выполняется на уровне L4 (TCP).
2. Балансировщик должен поддерживать сохранение выбора узла по IP-адресу источника (sticky session / source IP affinity), например balance source в HAProxy.
3. Внешний балансировщик для KubeAPI при установке кластера с провайдером Shturval v2 должен быть настроен до начала инсталляции кластера.

Пример настройки HAProxy (статическая конфигурация) #

#---------------------------------------------------------------------
# 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

Динамическое добавление бэкендов (CoreHA) #

Модуль shturval-coreha позволяет HAProxy динамически получать список узлов с Ingress Controller через DNS. Это удобно при масштабировании или миграции подов.

Настройка CoreHA:

1. Установите и включите Модуль поиска узлов с запущенными hostport сервисами (shturval-coreha) в разделе Сервисы и репозитории.
2. Настройте параметры чарта, например:

   config:
     zoneName: cluster-prod01-dc1.shturval
   

3. Примените ShturvalServicePatch к shturval-ingress-controller с лейблом ingress.cluster/name и включённым hostPort.
4. В HAProxy используйте resolvers и server-template:

resolvers coredns-cluster
    nameserver ns1 <api-server-vip>:1053
    accepted_payload_size 8192

backend cluster-prod01-dc1-ingress-http
    balance source
    mode tcp
    server-template daemonset 2 <label_value>.ingress.<zoneName>:80 check resolvers coredns-cluster init-addr none

Где <api-server-vip> — адрес API-сервера кластера, <zoneName> — значение config.zoneName в shturval-coreha, <label_value> — значение лейбла ingress.cluster/name.

Проверка: dig @<api-server-vip> -p 1053 <label_value>.ingress.<zoneName>.

Порты и направления трафика #

При использовании CoreHA балансировщик подключается к DNS-серверу модуля на порту 1053 (VIP Control Plane) для динамического разрешения имён бэкендов.

По провайдерам #

DNS и сетевые имена #

• Каждый узел кластера должен иметь уникальное сетевое имя.
• Полное сетевое имя узла должно быть корректным DNS-именем не длиннее 63 символов.
• Имя кластера должно быть уникальным в сочетании с DNS-зоной организации и образовывать корректный поддомен DNS.
• В DNS должна быть создана зона; для каждого узла кластера должна быть создана запись типа A в этой зоне.
• Для API-сервера кластера управления создаётся A-запись вида api.<cluster_name>.<base_domain>.
• Для Ingress кластера управления создаётся wildcard-запись вида *.<cluster_name>.<base_domain>.
• FQDN зеркала должен разрешаться в IP-адрес на машине shtil и на узлах кластера.

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

В закрытом контуре внешние облачные API в матрицах не используются; вместо внешнего Registry — зеркало в вашем периметре.

Схемы межсетевого взаимодействия #

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

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

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

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

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

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

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

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

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

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

Дополнительные требования #

Требования к браузерам #

Рекомендуемое разрешение монитора: 1498×906.

Поддерживаются #

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

• IE;
• Opera Mini;
• UC Browser for Android;
• QQ Browser;
• Baidu Browser;
• KaiOS Browser;
• Opera Mobile;
• Android Browser;
• Firefox for Android;
• Samsung Internet Browser;
• Safari on iOS.

Чек-лист перед установкой #

• Развёрнуто зеркало; есть бандл и лицензия Enterprise
• Узлы и машина shtil имеют доступ к зеркалу по HTTPS
• Если на машине shtil используется Docker и у зеркала самоподписной или корпоративный CA, СА добавлен в /etc/docker/certs.d/<registry-host>/ca.crt или зеркало настроено в insecure-registries
• Ресурсы и ОС соответствуют требованиям
• DNS, VIP или балансировщики подготовлены по сценарию
• Межсетевые экраны настроены по матрицам

Проверки командой строки — Подготовка.