Топология

На этой стадии необходимо выбрать топологию платформы и подготовить соответствующие ресурсы.

В обзоре архитектуры представлены два протестированных варианта топологии, их особенности, преимущества и недостатки. Это позволяет определить вариант топологии, наиболее подходящий для бизнес-планов организации. Следующий шаг состоит в планировании и подготовке ресурсов для выбранной топологии.

Ресурсы Kubernetes

Для развертывания центральных компонентов Astra Automation необходим кластер Kubernetes. Кластер может быть в собственном центре обработки данных или в облаке, см. Примеры подготовки кластера Kubernetes.

Необходимое количество ресурсов как в кластере Kubernetes, так и за его пределами существенно зависит от выбранной топологии.

Ресурс	Базовая	Уровень предприятия
PG gateway pod	1	3+
AC web pod	1	3+
AC task pod	1	3+
Automation Mesh ingress	1	3+ (примечание)
PAH web pod	1	3+
PAH api pod	1	3+
PAH worker pod	1	3+
PAH redis pod	1	1
PAH content pod	1	3+
PAH content storage	External	External
EDA api pod	1	3+
EDA activation pod	1	3+
EDA worker pod	1	3+
EDA stream pod	1	3+
EDA scheduler pod	1	3+
Redis pod	1	6+
PostgreSQL	Pod + PV	External
Execution plane	External execution node	External execution nodes + hop

В таблице использованы следующие сокращения:

• PG – Platform Gateway;

• AC – Automation Controller;

• PAH – Private Automation Hub;

• EDA – контроллер Event-Driven Automation;

• PV – Kubernetes Persistent Volume.

Примечание

Объект, созданный на основе ресурса (CR, Custom Resource) Automation Mesh ingress (AutomationControllerMeshIngress), нельзя реплицировать. Для балансировки нагрузки рекомендуется создавать несколько объектов этого типа, обеспечив для каждого из них уникальные параметры metadata.name и external_hostname.

Ручное масштабирование этих объектов, например командой kubectl scale, не поддерживается и приводит к отказу в работе системы.

Базовая топология

В базовой топологии для развертывания Astra Automation используется минимальное количество ресурсов.

Для обслуживания различных сегментов инфраструктуры Automation Controller подключается к сети Mesh, в которой установлены исполняющие узлы.

Требования к рабочему узлу Kubernetes

Минимальные требования к рабочему узлу, на котором развертываются все центральные компоненты Astra Automation:

Параметр	Минимальное значение	Рекомендуемое значение
Количество ядер CPU	4	≥ 8
Объем RAM	16 ГБ	≥ 32 ГБ
Дисковое пространство	100 ГБ	≥ 250 ГБ
Тип дискового накопителя	SSD	SSD
IOPS	3000	≥ 3000

Примечание

В таблице выше указаны значения ресурсов рабочего узла, если все поды необходимо установить именно на нем. Также развертывание может быть выполнено на более чем одном рабочем узле. Закрепление компонентов платформы за отдельными узлами описано в инструкции Закрепление компонентов за узлами.

В любом случае необходимо убедиться, что для установки подов доступны 16 ГБ RAM.

Если вместе с платформой развертывается Automation Dashboard, в конфигурации по умолчанию его поды запрашивают дополнительно 0,31 ядра CPU и около 1,45 ГиБ оперативной памяти, а также постоянный том объемом 8 ГиБ. Эти ресурсы необходимо предусмотреть сверх указанных выше (см. требования Automation Dashboard).

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

Для хранения данных Private Automation Hub требуется хранилище с поддержкой режима доступа ReadWriteMany (RWX), позволяющего нескольким подам выполнять чтение и запись одновременно.

При использовании файлового хранилища платформа взаимодействует с ним через драйвер CSI Kubernetes. Для работы Private Automation Hub не имеет значения конкретная технология хранения, если используемый StorageClass поддерживает следующую функциональность:

• создание Persistent Volume через CSI;

• режим доступа ReadWriteMany (RWX).

В качестве файлового хранилища могут использоваться, например, следующие варианты:

• Longhorn;

• CephFS;

• другие StorageClass с поддержкой RWX, совместимые с CSI.

Рекомендуемым вариантом является использование объектного хранилища S3, управляемого напрямую через HTTPS. Оно проще в настройке и обслуживании по сравнению с другими.

Хранить контент приватного реестра рекомендуется в хранилище S3, размеры которого зависят от объема контента. Для хранения контента, полученного из облачного реестра Automation Hub, необходимо зарезервировать 3 ГБ пространства. Для загрузки дополнительного контента, например из Ansible Galaxy, может понадобиться в несколько раз больший объем, но обычно не более 40 ГБ.

Требования к исполняющему узлу Astra Automation

К ВМ, используемой для установки исполняющего узла (exec node), предъявляются следующие минимальные требования.

Параметр	Значение
Количество ядер CPU	8
Объем RAM	16 ГБ
Дисковое пространство	60 ГБ
Тип дискового накопителя	SSD
IOPS	3000

Для загрузки образов среды исполнения исполняющему узлу необходим доступ к реестру образов платформы. Если сертификат TLS для узла реестра выпущен не публичным удостоверяющим центром, на узле настраивают доверие этому сертификату, как описано в способах настройки Podman, – системным способом: через каталог /etc/containers/certs.d либо системное хранилище доверия. Системные сертификаты действуют и для сервиса Podman, запущенного с привилегиями учетной записи, отличной от root (режим rootless). Вариант с каталогом сертификатов в домашнем каталоге пользователя на этом шаге неприменим: служебная учетная запись, от имени которой работает Podman, создается позже, сценарием подключения узла.

Для запуска контейнеров узлу требуется Podman в режиме rootless, в котором работают среды исполнения заданий. Устанавливать Podman заранее не требуется, так как сценарий подключения узла устанавливает его и создает служебную учетную запись (по умолчанию awx). Сценарий устанавливает пакеты Podman из репозиториев операционной системы, поэтому узлу необходимы настроенные основной (main) и расширенный (extended) репозитории Astra Linux Special Edition. В Astra Linux Special Edition 1.7 пакеты Podman доступны начиная с оперативного обновления 1.7.2, как описано в инструкции по установке Podman.

Настройка сетевых фильтров

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

Источник	Назначение	Служба	Порт TCP
Admin workstation	Kubernetes cluster	HTTPS	6443
User workstation	Platform Gateway	HTTP/HTTPS	80/443
Установочный узел	Рабочие узлы Kubernetes	SSH	22
Рабочий узел Kubernetes	Platform Gateway (реестр Private Automation Hub)	HTTPS	443
Рабочий узел Kubernetes	Внешний реестр образов	HTTPS	443
Поды Private Automation Hub	External S3	HTTPS	443
Поды Private Automation Hub	Облачный реестр Automation Hub	HTTPS	443
Поды Automation Controller и Event-Driven Automation	Внешние системы контроля версий и источники событий	HTTPS/SSH	443/22
Поды Event-Driven Automation	Platform Gateway	HTTPS	443
Внешние источники событий	Platform Gateway	HTTPS	443
Automation Controller	Execution node	Receptor	27199
Execution node	Platform Gateway	HTTP/HTTPS	80/443
Execution node	Реестр образов платформы	HTTPS	443
Execution node	Управляемый сегмент	SSH	22

Платформа публикует реестр образов через тот же Ingress, что и Platform Gateway, то есть реестр доступен по тому же адресу и порту 443. При использовании стороннего реестра, например облачного реестра Automation Hub, узлу необходим доступ к адресу этого реестра.

Среды исполнения и среды принятия решений для подов заданий загружает служба containerd самого узла, поэтому доступ к реестру необходим рабочим узлам кластера.

Поды Event-Driven Automation вызывают API Automation Controller через шлюз платформы, если в полномочии типа Astra Automation Platform указан внешний адрес платформы (см. описание полномочий). Такой вызов выполняют действия свода правил, например run_job_template, которому необходим параметр --controller-url. При развертывании без доступа к интернету она берет их из Private Automation Hub по доменному имени шлюза платформы, а при развертывании с доступом к интернету – из внешнего реестра, заданного в манифесте приложения.

Примечание

Таблица описывает только внешние границы кластера. Потоки между подами внутри кластера в нее не входят, так как их разрешает сетевая политика Kubernetes, а не внешние сетевые фильтры.

Топология уровня предприятия

Эта топология по сравнению с предыдущей преследует две основные цели, для достижения которых применяются соответствующие изменения:

• Для обеспечения высокой доступности все ресурсы Kubernetes имеют несколько реплик (не менее трех) на разных рабочих узлах кластера. Для еще большего повышения уровня доступности используют кластер Kubernetes, распределенный по зонам доступности.

• Для управления сложными распределенными инфраструктурами задействована сеть Mesh, в которой предусматривают распределение нагрузки по множеству исполняющих узлов (exec nodes) с применением переходных узлов (hop nodes) для маршрутизации трафика. Для критически важных сегментов используют несколько исполняющих узлов.

Требования к рабочему узлу Kubernetes

Минимальные требования к ресурсам для развертывания всех центральных компонентов Astra Automation с учетом только одной реплики для каждого Kubernetes pod остаются теми же, что и для базовой топологии.

Примечание

Для оценки полного объема требуемых ресурсов необходимо учитывать количество реплик.

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

Хранить контент приватного реестра рекомендуется в хранилище S3, размеры которого зависят от объема контента. Для хранения контента, полученного из облачного реестра Automation Hub, необходимо зарезервировать 3 ГБ пространства. С учетом дальнейшего расширения рекомендуемый объем составляет 40 ГБ.

Требования к исполняющему и переходному узлам Astra Automation

К ВМ, используемой для установки переходного или исполняющего узла, предъявляются следующие минимальные требования.

• количество ядер CPU: 8;

• объем RAM: 16 ГБ;

• дисковое пространство: 60 ГБ;

• скорость операций ввода-вывода, IOPS: 3000.

Для исполняющего узла требования к доступу в реестр образов, доверию его сертификату и наличию Podman совпадают с требованиями базовой топологии. Переходному узлу доступ к реестру образов и Podman не требуются: задания на нем не выполняются.

Требования к внешней СУБД PostgreSQL

Требования к внешней СУБД едины для всех моделей развертывания и приведены в инструкции Внешняя СУБД PostgreSQL: версия, расширение hstore, базы данных и их владельцы, поддержка ICU, лимит подключений, служба Autovacuum и стабильная точка подключения отказоустойчивого кластера.

Для развертывания в кластере Kubernetes адрес стабильной точки подключения указывают в поле host секретов подключения к внешней СУБД (см. описание манифестов).

Настройка сетевых фильтров

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

Источник	Назначение	Служба	Порт TCP
Admin workstation	Kubernetes cluster	HTTPS	6443
User workstation	Platform Gateway	HTTP/HTTPS	80/443
Установочный узел	Рабочие узлы Kubernetes	SSH	22
Рабочие узлы Kubernetes	Platform Gateway (реестр Private Automation Hub)	HTTPS	443
Рабочие узлы Kubernetes	Внешний реестр образов	HTTPS	443
Поды Private Automation Hub	External S3	HTTPS	443
Поды Private Automation Hub	Облачный реестр Automation Hub	HTTPS	443
All pods	External PostgreSQL	TCP	5432
Поды Automation Controller и Event-Driven Automation	Внешние системы контроля версий и источники событий	HTTPS/SSH	443/22
Поды Event-Driven Automation	Platform Gateway	HTTPS	443
Внешние источники событий	Platform Gateway	HTTPS	443
Поды Automation Controller	Execution nodes, hop nodes	Receptor	27199
Execution nodes, hop nodes	Mesh Ingress (external_hostname)	Receptor поверх TLS	443
Execution nodes	Platform Gateway	HTTP/HTTPS	80/443
Execution nodes	Реестр образов платформы	HTTPS	443
Execution nodes	Управляемый сегмент	SSH	22

Платформа публикует реестр образов через тот же Ingress, что и Platform Gateway, то есть реестр доступен по тому же адресу и порту 443. При использовании стороннего реестра, например облачного реестра Automation Hub, узлу необходим доступ к адресу этого реестра.

Связь плоскости управления с узлами плоскости исполнения однонаправленная, и направление выбирают при первом подключении узла параметром peers_from_control_nodes:

• peers_from_control_nodes: false – соединение устанавливает сам узел, поэтому узлу необходим доступ к переходному узлу внутри кластера (Mesh Ingress) по доменному имени из поля external_hostname и порту 443. Контроллер Ingress передает такое соединение без расшифровки, для чего его запускают в режиме SSL passthrough (см. инструкцию по настройке контроллера Ingress).

• peers_from_control_nodes: true – соединение устанавливает плоскость управления, поэтому поды Automation Controller открывают соединение к узлу по порту 27199.

В одной сети Mesh применяют оба направления, подключая часть узлов к переходному узлу внутри кластера, а часть – напрямую с плоскости управления.

Поды Event-Driven Automation вызывают API Automation Controller через шлюз платформы, если в полномочии типа Astra Automation Platform указан внешний адрес платформы (см. описание полномочий). Такой вызов выполняют действия свода правил, например run_job_template, которому необходим параметр --controller-url. Если в полномочии указан адрес внутри кластера, этот поток за его пределы не выходит.

Примечание

Таблица описывает только внешние границы кластера. Потоки между подами внутри кластера в нее не входят, так как их разрешает сетевая политика Kubernetes, а не внешние сетевые фильтры.

Отказоустойчивость точки входа

Точкой входа в платформу служит контроллер Ingress кластера. Чтобы вход не зависел от отдельного рабочего узла, перед контроллером ставят внешний балансировщик с виртуальным адресом (VIP) – программный или аппаратный. Тот же балансировщик объединяет несколько кластеров под одним адресом, если платформу развертывают в нескольких кластерах.

При такой схеме сетевые фильтры настраивают на следующие связи:

• рабочие станции пользователей и администраторов – к VIP балансировщика по порту 443;

• балансировщик – к контроллеру Ingress по порту 443 или по порту NodePort, на котором опубликован контроллер;

• исполняющие и переходные узлы – к VIP балансировщика по порту 443, так как шлюз платформы и реестр образов они адресуют по тому же доменному имени, что и пользователи;

• рабочие узлы кластера – к VIP балансировщика по порту 443, так как служба containerd адресует Private Automation Hub по доменному имени шлюза платформы и потому идет во внешнюю точку входа, а не напрямую в кластер.

• поды Event-Driven Automation – к VIP балансировщика по порту 443, если в полномочии для Automation Controller указан внешний адрес платформы, так как вызов API выходит из кластера и приходит обратно через ту же точку входа. Такой возврат трафика на себя допускают не все балансировщики, поэтому проверьте поддержку режима hairpin (NAT loopback) до развертывания.

Для объекта Mesh Ingress предусматривают отдельное доменное имя и отдельный VIP. Балансировщик передает это соединение на уровне TCP и не завершает TLS, так как сеанс TLS завершает переходный узел внутри кластера.

Адрес, по которому платформа доступна снаружи, задают в поле public_base_url манифеста приложения, если он отличается от значения hostname (см. описание манифестов).