База знаний
Войти

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

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

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

  • на всех узлах кластера должна использоваться одна и та же версия ядра ОС;
  • на всех узлах кластера должны быть установлены следующие пакеты:
    • openssh-server;
    • пакеты, необходимые для установки openssh-server.

Комплекс работает под управлением ОС, приведенных в разделе Кластер управления таблица 1.

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

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

Если необходимо выставить время без синхронизации (например, такое встречается на 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

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

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

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

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

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

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

Следует обратить внимание, что в пакете лицензии РОСА Кубис установлен лимит по количеству Worker-узлов в Комплексе. В случае превышения лимита на всех экранах графического интерфейса кластера отобразится уведомление.

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

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

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

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

Важно:

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

В таблицах 1 и 2 приведены системные требования для кластера управления в разных вариантах.

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

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

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

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

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

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

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

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

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

  • Балансировку сетевой нагрузки требуется реализовывать только на уровне L4.
  • Сетевой балансировщик должен поддерживать механизм сохранения выбора конечного узла на основании 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 при отсутствии внешнего балансировщика.

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

(<cluster_name>.<base_domain>)

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

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

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

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

где:

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

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

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

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

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

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

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

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