Требования

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание! Внимание: Кластер управления, состоящий только из одного Control Plane узла, не рекомендуется для production, т.к. не обеспечивает отказоустойчивость. Однако при необходимости на нём можно развернуть до 5 клиентских кластеров.

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

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

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

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

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

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

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

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

Режим, в котором кластер управления используется и для рабочих нагрузок. Подробнее о режиме — в разделе Режимы работы кластера управления.

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

Для инсталляции потребуется утилита shtil. Скачивание и работа с утилитой описаны в разделе подготовки к инсталляции. Машина shtil: утилиту shtil необходимо запускать с хоста с ОС Linux. Минимум свободных ресурсов: 3 vCPU, 3 GiB RAM, 20 GiB диск. На машине shtil должны быть установлены Docker или Podman (см. Подготовку).

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

Ниже приведен список поддерживаемых операционных систем машины запуска shtil. При необходимости воспользуйтесь фильтрами, что посмотреть рекомендуемые ОС для разных сценариев инсталляции. Рекомендации для открытого и закрытого окружений отличаются.

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

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

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

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

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

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

• Узлы должны резолвить FQDN репозитория образов r.shturval.tech и другие сетевые имена, используемые выбранным сценарием.
• 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 и все узлы кластера должны иметь прямой исходящий доступ к r.shturval.tech: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 используется на сетевом балансировщике нагрузки.
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>.

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

В матрицах ниже Registry — репозиторий образов r.shturval.tech (HTTPS, 443), если не указано иное.

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

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 #

OpenStack с внешним балансировщиком для 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.

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