Общие требования к установке Nova Container Platform

Вы можете установить кластер Nova Container Platform в любой подготовленной инфраструктуре, включая виртуализацию и облачные среды.

1. Доступ к интернет-ресурсам

В Nova Container Platform для установки кластера по умолчанию требуется доступ к сети Интернет.

В вашей инфраструктуре должен быть настроен доступ в Интернет к следующим ресурсам:

Ресурс DNS-имя Порт IP-адреса

Хранилище образов

hub.nova-platform.io

https/443

217.73.63.211/32
217.73.57.4/32
185.12.28.202/32

Сервис проверки лицензии

access.nova-platform.io

https/443

217.73.63.211/32
217.73.57.4/32
185.12.28.202/32

Сервис доставки ПО

code.nova-platform.io

https/443

217.73.63.211/32
217.73.57.4/32
185.12.28.202/32

Сервис настройки ПО

sun.nova-platform.io

https/8140

217.73.63.211/32
217.73.57.4/32
185.12.28.202/32

Если инфраструктура, в которой выполняется установка вашего кластера, не может иметь прямого доступа в Интернет, вы можете выполнить установку платформы в закрытом сетевом окружении.

2. Требования к установке в подготовленной пользователем инфраструктуре (UPI)

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

В данном разделе описаны требования для развертывания Nova Container Platform в подготовленной пользователем инфраструктуре.

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

Минимальная конфигурация кластера Nova Container Platform включает следующий набор узлов:

Узел Описание

1 мастер-узел

Мастер-узел содержит ключевые компоненты Nova Container Platform и Kubernetes.

1 инфраструктурный узел

Инфраструктурный узел содержит служебные компоненты Nova Container Platform.

1 узел для пользовательских нагрузок

Рабочий узел предоставляется пользователю для запуска собственных нагрузок.

Минимальная конфигурация кластера Nova Container Platform не отличается по набору основных компонентов от любой другой конфигурации кластера, однако количество узлов минимальной конфигурации не обеспечивает непрерывность работы кластера в случае отказа одного из узлов. Поэтому данная конфигурация не предназначена для эксплуатации в продуктивных средах и может использоваться только в целях ознакомления или разработки.

Рекомендуемая конфигурация высокодоступного кластера Nova Container Platform включает следующий набор узлов:

Узел Описание

3 мастер-узла

Мастер-узел содержит ключевые компоненты Nova Container Platform и Kubernetes.

3 инфраструктурных узла

Инфраструктурный узел содержит служебные компоненты Nova Container Platform.

2 и более узлов для балансировки входящих запросов

Выделенные узлы Ingress для балансировки входящих запросов.

2 и более узлов для пользовательских нагрузок

Рабочий узел предоставляется пользователю для запуска собственных нагрузок.

На узлы кластера Nova Container Platform должна быть установлена поддерживаемая операционная система. Получить дополнительную информацию о поддерживаемых операционных системах можно в разделе Перечень матриц совместимости и протестированных интеграций.

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

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

Для запуска кластера Nova Container Platform в минимальной конфигурации необходимо следующее количество ресурсов:

Узел Количество ОС vCPU RAM Диск IOPS

Мастер-узел

1

AlmaLinux
РЕД ОС
Astra Linux

4

8 GB

32 GB SSD

300+

Инфраструктурный узел

1

AlmaLinux
РЕД ОС
Astra Linux

8

16 GB

128 GB SSD

1000+

Рабочий узел

1 и более

AlmaLinux
РЕД ОС
Astra Linux

2

4 GB

32 GB SSD

300+

Для запуска кластера Nova Container Platform в рекомендуемой конфигурации необходимо следующее количество ресурсов:

Узел Количество ОС vCPU RAM Диск IOPS

Мастер-узел

3

AlmaLinux
РЕД ОС
Astra Linux

4

8 GB

32 GB SSD

300+

Инфраструктурный узел

3

AlmaLinux
РЕД ОС
Astra Linux

6

12 GB

128 GB SSD

1000+

Узел балансировки входящих запросов (Ingress)

2 и более

AlmaLinux
РЕД ОС
Astra Linux

2

4 GB

32 GB SSD

1000+

Рабочий узел

2 и более

AlmaLinux
РЕД ОС
Astra Linux

2

4 GB

32 GB SSD

300+

Платформа Nova и Kubernetes чувствительны к производительности диска, поэтому всегда рекомендуется использовать более быстрое хранилище, особенно для хранилища etcd на мастер-узлах.

2.3. Требования к настройке сети

Узлы кластера Nova Container Platform поддерживают использование IP-адресов, настроенных как с помощью DHCP, так и заданных статически. После того, как сетевой интерфейс узла настроен и запущен процесс установки кластера, узлы устанавливают HTTPS-соединение с сервисом настройки ПО, получают необходимую целевую конфигурацию и применяют ее самостоятельно.

  • В случае использования DHCP-сервера для настройки сетевых интерфейсов узлов кластера, необходимо настроить DHCP-сервер на предоставление постоянных IP-адресов и сведений о DNS-сервере узлам кластера.

  • Динамическая настройка имени хоста (hostname) должна быть отключена в ОС узла кластера.

  • Кластеры Nova Container Platform на текущий момент не поддерживают IPv6.

2.4. Требования к межсетевому экранированию

Для корректной установки и функционирования Nova Container Platform убедитесь, что в пределах сетевого сегмента (сегментов), в котором располагаются узлы платформы, настроен представленный ниже перечень сетевых правил либо ограничения по сетевому взаимодействию узлов отсутствуют.

2.4.1. Установщик платформы

Источник Адресат Тип трафика Порт/Протокол Описание

Установщик nova-ctl

Мастер-узлы

Входящий

6443/tcp

Kubernetes API

Установщик nova-ctl

Мастер-узлы

Входящий

8200/tcp

Secrets Manager API

Установщик nova-ctl

Все узлы

Входящий

22/tcp

SSH

Установщик nova-ctl

Инфраструктурные узлы

Входящий

80/tcp

Ingress Nginx Controller HTTP

Установщик nova-ctl

Инфраструктурные узлы

Входящий

443/tcp

Ingress Nginx Controller HTTPS

2.4.2. Мастер-узлы кластера Kubernetes

Источник Адресат Тип трафика Порт/Протокол Описание

Все узлы, АРМ пользователей платформы

Мастер-узлы

Входящий

6443/tcp

Kubernetes API

Все узлы

Мастер-узлы

Входящий

8200/tcp

Secrets Manager API

Все узлы

Мастер-узлы

Входящий

2379/tcp

Etcd Client Requests

Инфраструктурные узлы

Мастер-узлы

Входящий

10259/TCP

Kubernetes Scheduler metrics

Инфраструктурные узлы

Мастер-узлы

Входящий

10257/TCP

Kubernetes Controller Manager metrics

Мастер-узлы

Мастер-узлы

Двунаправленный

8201/tcp

Secrets Manager Cluster Endpoint

Мастер-узлы

Мастер-узлы

Двунаправленный

2380/tcp

Etcd Peer Requests

Мастер-узлы

Все узлы

Исходящий

10250/TCP

Kubelet

2.4.3. Инфраструктурные узлы кластера Kubernetes

Источник Адресат Тип трафика Порт/Протокол Описание

Все узлы, АРМ пользователей платформы

Инфраструктурные узлы

Входящий

80/tcp

Ingress Nginx Controller HTTP

Все узлы, АРМ пользователей платформы

Инфраструктурные узлы

Входящий

443/tcp

Ingress Nginx Controller HTTPS

Все узлы

Инфраструктурные узлы

Входящий

8443/tcp

Ingress Nginx Controller Validating webhook

Инфраструктурные узлы

Все узлы

Исходящий

9100/tcp

Prometheus Node Exporter

Инфраструктурные узлы

Все узлы

Исходящий

9962/tcp

Cilium Agent metrics

Инфраструктурные узлы

Все узлы

Исходящий

9963/tcp

Cilium Operator metrics

Инфраструктурные узлы

Мастер-узлы

Исходящий

10259/TCP

Kubernetes Scheduler metrics

Инфраструктурные узлы

Мастер-узлы

Исходящий

10257/TCP

Kubernetes Controller Manager metrics

Инфраструктурные узлы

Все узлы

Исходящий

10250/TCP

Kubelet

Инфраструктурные узлы

Инфраструктурные узлы

Исходящий

10249/tcp

Kube Proxy metrics

2.4.4. Узлы балансировки входящих запросов кластера Kubernetes (Ingress-узлы)

Источник Адресат Тип трафика Порт/Протокол Описание

Все узлы, АРМ пользователей платформы

Ingress-узлы

Входящий

80/tcp

Ingress Nginx Controller HTTP

Все узлы, АРМ пользователей платформы

Ingress-узлы

Входящий

443/tcp

Ingress Nginx Controller HTTPS

Все узлы

Ingress-узлы

Входящий

8443/tcp

Ingress Nginx Controller Validating webhook

Инфраструктурные узлы

Ingress-узлы

Входящий

10254/TCP

Ingress Nginx Controller metrics

Если в конфигурации кластера Nova Container Platform не используются выделенные Ingress-узлы, то все правила для Ingress-узлов необходимо применить к рабочим узлам (Worker).

2.4.5. Все узлы кластера Kubernetes

Источник Адресат Тип трафика Порт/Протокол Описание

Все узлы

Все узлы

Двунаправленный

179/tcp

BGP

Все узлы

Все узлы

Двунаправленный

4789/udp

VXLAN Overlay

Все узлы

Все узлы

Двунаправленный

8472/udp

VXLAN Overlay

Все узлы

Все узлы

Двунаправленный

IPIP (4)

IP in IP Protocol

Все узлы

Все узлы

Двунаправленный

4240/tcp

Cilium Health Check

Все узлы

Все узлы

Двунаправленный

ICMP (8/0)

Cilium Health Check

Все узлы

Все узлы

Двунаправленный

4244/tcp

Cilium Hubble server

Все узлы

Все узлы

Двунаправленный

4245/tcp

Cilium Hubble relay

Инфраструктурные узлы

Все узлы

Входящий

9100/tcp

Prometheus Node Exporter

Инфраструктурные узлы

Все узлы

Входящий

9962/tcp

Cilium Agent metrics

Инфраструктурные узлы

Все узлы

Входящий

9963/tcp

Cilium Operator metrics

Инфраструктурные узлы

Все узлы

Входящий

10249/tcp

Kube Proxy metrics

Инфраструктурные узлы и мастер-узлы

Все узлы

Входящий

10250/tcp

Kubelet

Все узлы

Мастер-узлы

Исходящий

2379/tcp

Etcd Client Requests

Все узлы

Мастер-узлы

Исходящий

8200/tcp

Secrets Manager API

Все узлы

Инфраструктурные узлы

Исходящий

80/tcp

Ingress Nginx Controller HTTP (Internal)

Все узлы

Инфраструктурные узлы

Исходящий

443/tcp

Ingress Nginx Controller HTTPS (Internal)

Все узлы

Инфраструктурные узлы, Ingress-узлы

Исходящий

8443/tcp

Ingress Nginx Controller Validating webhook

Все узлы

Мастер-узлы

Исходящий

6443/tcp

Kubernetes API

Если установку Nova Container Platform планируется выполнять с использованием HTTP-прокси, не забудьте добавить в список разрешающих правил доступ (исходящий трафик) к HTTP-прокси со всех узлов платформы.

2.4.6. АРМ пользователей платформы

Источник Адресат Тип трафика Порт/Протокол Описание

АРМ пользователей платформы

Ingress-узлы

Исходящий

80/tcp

Ingress Nginx Controller HTTP (Public)

АРМ пользователей платформы

Ingress-узлы

Исходящий

443/tcp

Ingress Nginx Controller HTTPS (Public)

АРМ пользователей платформы

Инфраструктурные узлы

Исходящий

80/tcp

Ingress Nginx Controller HTTP (Internal)

АРМ пользователей платформы

Инфраструктурные узлы

Исходящий

443/tcp

Ingress Nginx Controller HTTPS (Internal)

АРМ пользователей платформы

Мастер-узлы

Исходящий

6443/tcp

Kubernetes API

При развертывании Nova Container Platform в публичных облаках за контроль сетевого взаимодействия, как правило, отвечает не только функционал списков контроля доступа (Network ACL), а также функционал групп безопасности. В данном случае убедитесь, что настроенные в инфраструктуре правила не пересекаются и не блокируют друг друга. Вы также можете добавить узлы платформы в одну общую группу безопасности, в рамках которой сетевое взаимодействие не ограничивается.

2.5. Требования к настройке синхронизации времени

На всех узлах кластера Nova Container Platform должны быть выполнена настройка синхронизации времени с приоритетным сервером. Данный сервер может быть как локальным в предоставляемой пользователем инфраструктуре, так и публичным.

Информацию по настройке службы синхронизации времени Chrony вы можете найти в разделе Подготовка к установке.

2.6. Требования к системе разрешения имен DNS

Nova Container Platform предусматривает несколько режимов работы с системой разрешения имен DNS. Вы можете ознакомиться с режимами и доступными параметрами настройки в разделе документации об архитектуре DNS.

В зависимости от выбранного режима работы, конфигурации кластера и дополнительных параметров, следующие DNS-записи могут быть созданы в пользовательской инфраструктуре:

Компонент Пример записи Описание

Kubernetes API

api.k8s.nova.internal

DNS-запись типа A или CNAME разрешает адреса мастер-узлов кластера или внешнего балансировщика Kubernetes API.

Внутренний Ingress-контроллер

*.apps.nova.internal

DNS-запись по умолчанию типа A или CNAME разрешает адреса инфраструктурных узлов или адрес пользовательского сетевого балансировщика.

Внешний Ingress-контроллер

*.public.nova.internal

DNS-запись типа A или CNAME разрешает адреса узлов балансировки входящих запросов или адрес пользовательского сетевого балансировщика.

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

Вы можете воспользоваться примером настройки DNS-сервера BIND, если планируете использовать внешний режим работы DNS. В примере используется DNS-зона по умолчанию apps.k8s.nova.internal и DNS-имя по умолчанию api.k8s.nova.internal для Kubernetes API.

$TTL 1W
@   IN  SOA ns1.nova.internal.  root (
            2024070700  ; serial
            3H          ; refresh (3 hours)
            30M         ; retry (30 minutes)
            2W          ; expiry (2 weeks)
            1W )        ; minimum (1 week)
    IN  NS      ns1.nova.internal.
    IN  MX 10   smtp.nova.internal.
;
;
ns1.nova.internal.          IN  A   192.168.1.5
smtp.nova.internal.         IN  A   192.168.1.5
;
api.k8s.nova.internal.      IN  A       192.168.10.5
apps.k8s.nova.internal.     IN  A       192.168.10.10
apps.k8s.nova.internal.     IN  A       192.168.10.11
apps.k8s.nova.internal.     IN  A       192.168.10.12
*.apps.k8s.nova.internal.   IN  CNAME   apps.k8s.nova.internal.
;

2.7. Требования к сетевым балансировщикам

Для работы внутренних компонентов Nova Container Platform не требуется наличие внешних сетевых балансировщиков в пользовательской инфраструктуре.

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

Однако, если вы хотите обеспечить внешний отказоустойчивый доступ пользователей к компонентам Kubernetes API, Ingress, следующие требования к настройке собственных сетевых балансировщиков должны быть учтены:

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

  • Поддерживается только Layer-4 балансировка (Raw TCP, SSL Passthrough).

Информация

Для корректной работы с Kubernetes API не требуется настройка сохранения сессий (персистентность).

Следующие порты должны быть настроены на сетевом балансировщике:

Порт Backend-узлы Внутренний доступ Внешний доступ Описание

6443

Мастер-узлы. Для проверки доступности узла (healthcheck) необходимо настроить HTTP-проверку, используя путь /readyz.

Да

Да

Kubernetes API

Балансировщики Ingress предоставляют общую точку подключения пользователям и сервисам для работы с публикуемыми через Ingress-контроллеры веб-сервисами, также сервисами Kubernetes, для которых используется Layer-4 балансировка средствами Ingress-контроллера.

  • Поддерживается Layer-4 балансировка (Raw TCP, Raw UDP, SSL Passthrough).

  • Поддерживается Layer-7 балансировка для доступа к публикуемым веб-сервисам.

Информация

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

Следующие порты должны быть настроены на сетевом балансировщике:

Порт Backend-узлы Внутренний доступ Внешний доступ Описание

80

Инфраструктурные узлы. Для проверки доступности узла (healthcheck) необходимо настроить HTTP-проверку, используя путь /healthz.

Да

Да

Доступ к служебным веб-сервисам Ingress по HTTP.

443

Инфраструктурные узлы. Для проверки доступности узла (healthcheck) необходимо настроить HTTP-проверку, используя путь /healthz.

Да

Да

Доступ к служебным веб-сервисам Ingress по HTTPS.

53

Инфраструктурные узлы

Да

Да

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

80

Узлы балансировки входящего трафика (Ingress). Для проверки доступности узла (healthcheck) необходимо настроить HTTP-проверку, используя путь /healthz.

Да

Да

Доступ к публичным веб-сервисам Ingress по HTTP.

443

Узлы балансировки входящего трафика (Ingress). Для проверки доступности узла (healthcheck) необходимо настроить HTTP-проверку, используя путь /healthz.

Да

Да

Доступ к публичным веб-сервисам Ingress по HTTPS.

Указанный выше перечень необходимых для настройки портов может быть расширен при использовании собственных дополнительных правил TCP и UDP балансировки.

При установке Nova Container Platform в минимальной конфигурации роль узлов балансировки входящего трафика (Ingress) выполняют рабочие узлы, выделенные для пользовательских нагрузок.