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

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

1. На всех узлах кластера должна использоваться одна и та же версия ядра операционной системы (ОС).
2. На всех узлах кластера должны быть установлены следующие пакеты:

• openssh-server;
• пакеты, необходимые для установки openssh-server.

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

Платформа работает под управлением следующих операционных систем:

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

Синхронизация времени #

Инструкция по синхронизации времени на операционных системах:

1. Для Astra Linux SE выполните следующие команды в терминале:

sudo apt-get install ntp
sudo systemctl start ntp 
sudo systemctl enable ntp 

2. Для Debian выполните следующие команды в терминале:

sudo apt-get install ntp
sudo systemctl start ntp 
sudo systemctl enable ntp

3. Для Ubuntu выполните следующие команды в терминале:

sudo apt-get install ntp
sudo systemctl start ntp 
sudo systemctl enable ntp 

4. Для RedOs выполните следующие команды в терминале:

sudo yum install ntp
sudo systemctl start ntpd
sudo systemctl enable ntpd

5. Для Rosa выполните следующие команды в терминале:

sudo apt-get install ntp
sudo systemctl start ntp 
sudo systemctl enable ntp 

6. Для Rocky Linux выполните следующие команды в терминале:

sudo yum install chrony 
sudo systemctl start chronyd 
sudo systemctl enable chronyd

7. Для RHEL выполните следующие команды в терминале:

sudo yum install chrony 
sudo systemctl start chronyd 
sudo systemctl enable chronyd

8. Для Alt Linux выполните следующие команды в терминале:

sudo apt-get install chrony 
sudo systemctl start chronyd 
sudo systemctl enable chronyd

Вышеперечисленные операционные системы используют программы NTP или Chrony для синхронизации времени. После выполнения команд, система будет синхронизирована с серверами времени.

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

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

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

1. Для виртуальных IP-адресов ControlPlane всегда используется второй IP-адрес в выделенной подсети.
2. Все узлы кластера имеют доступ к зеркалу (Registry).

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

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

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

Метрики хранятся 7 дней, логи ротируются по заполнению.

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

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

Для клиентских кластеров введено понятие инфраструктурного узла - Infra Worker - это такой Worker узел, на котором развернуты системные сервисы кластера. Требования ресурсам для развертывания кастомных сервисов зависят от нагрузки самих сервисов.

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

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

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

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

1. Балансировку сетевой нагрузки требуется реализовывать только на уровне L4.
2. Сетевой балансировщик должен поддерживать механизм сохранения выбора конечного узла на основании IP-адреса источника.

Пример конфигурации 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:30080 check
    server worker2 10.11.13.5:30080 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:30443 check
    server worker2 10.11.13.5:30443 check
# где
# 10.11.13.100 - IP внешнего балансировщика
# 10.11.13.1 - master1
# 10.11.13.2 - master2
# 10.11.13.3 - master3
# 10.11.13.4 - worker1
# 10.11.13.5 - worker2

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

Хост с зеркалом #

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

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

• должны резолвить хост с зеркалом по действующему FQDN;
• SElinux не должен быть в статусe disabled. Если SElinux в статусе disabled – до начала установки необходимо изменить конфиг /etc/selinux/config и перезагрузить хост;
• недоступные репозитории должны быть отключены или удалены (например, родные репозитории дистрибутива);
• для linux пользователя должен быть создан домашний каталог в операционной системе (например, /home/shturval)

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

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

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

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

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

1. Для установки одного кластера требуется два виртуальных IP адреса (VIP адреса), т. е. они не должны быть настроены на каком-либо узле кластера.
2. Первый VIP-адрес должен принадлежать той же подсети, что и IP-адреса узлов с ролью Master. Он используется для API-сервера кластера.
3. Второй VIP-адрес должен использоваться на сетевом балансировщике нагрузки.

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

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

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

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

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

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

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

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

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

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

(<cluster_name>.<base_domain>) 

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

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

Предъявляются следующие требования:

1. В системе DNS должна быть создана зона.
2. Для каждого узла кластера должны быть созданы записи с типом A в единственной доменной зоне.
3. Созданные записи должны соответствовать следующим положениям, изложенным в таблице ниже.

Требования к DNS записям #

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

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

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

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

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

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

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