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

Развернуть все Свернуть все

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

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

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

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

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

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

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

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

timedatectl set-local-rtc true

timedatectl set-local-rtc false

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

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. Для Alt Linux выполните следующие команды в терминале.

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

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

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

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

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

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

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

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

Количество узлов в кластере определяется требованиями к вычислительным ресурсам прикладного ПО с учетом факторов резервирования и механизмов обновления. Обратите внимание! В пакете лицензии платформы “Штурвал” установлен лимит по количеству Worker-узлов в платформе. В случае превышения лимита на всех экранах графического интерфейса кластера отобразится уведомление.

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

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

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

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

Обратите внимание!

• Кластер управления, развернутый только на одном Master-узле не должен быть использован в prod-like средах.
• На кластере управления в такой конфигурации можно развернуть до 5 клиентских кластеров.
• При необходимости после инсталляции с помощью провайдера Shturvalv2 можно добавить дополнительные узлы в кластер управления для полнофункциональной эксплуатации.

Минимальные системные требования кластера управления c 1 Master-узлом:

Минимальные системные требования кластера управления с 1 Master-узлом и 3-мя Worker-узлами:

Минимальные системные требования для STAND-ALONE кластера

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

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

Минимальные системные требования для STAND-ALONE кластера на одном Master-узле:

Минимальные системные требования для STAND-ALONE кластера с 1 Master-узлом и 2-мя 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 (permissive или disabled);
• недоступные репозитории должны быть отключены или удалены (например, родные репозитории дистрибутива);
• в системе должны быть установлены пакеты iptables и gnupg;
• для linux пользователя должен быть создан домашний каталог в операционной системе (например, /home/shturval).

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

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

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

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

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

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

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

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

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

При развертывании ПО с использованием сети Интернет всем узлам в кластере должен быть предоставлен доступ к 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 без указания пароля.

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

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

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

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