Топология в Kubernetes

Содержание

Топология в Kubernetes#

Платформа Astra Automation может быть целиком или частично реализована как комплексное приложение внутри среды Kubernetes. Жизненный цикл платформы обеспечивается с помощью операторов Kubernetes. Возможны различные варианты топологии, как представлено далее.

Сравнение топологий#

Сравнение топологий развертывания платформы поможет принять правильное решение для вашего бизнеса. По сравнению с реализацией на ВМ переход от одной топологии к другой в рамках Kubernetes представляется гораздо проще.

Топология	Дублирование с помощью ReplicaSet	Внешние ресурсы	Область применения
Базовая (Growth)	Отсутствует	- Хранилище контента в S3 - Automation Mesh	Распределенная автоматизация
Уровень предприятия (Enterprise)	3+ replicas	- Хранилище контента в S3 - PostgreSQL - Automation Mesh - Load Balancers	- Критически важные системы - Крупномасштабная автоматизация - Высокая доступность (24/7) - Обеспечение особых требований

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

Эта топология часто используется для начального развертывания платформы с прицелом на ее дальнейшее развитие и переходом на топологию уровня предприятия. Она обеспечивает быстрое развертывание с использованием минимальных ресурсов.

Операторы (Astra Automation operators) создают компоненты платформы в пространстве имен astra-automation:

Шлюз платформы (Platform Gateway) реализован в gateway pod со следующими контроллерами Kubernetes:
- Приемник сетевых пакетов ingress обеспечивает маршрутизацию запросов из API/UI на соответствующие компоненты платформы.
- Контроллер service обеспечивает связь внутри кластера Kubernetes.
Оператор, управляющий этим компонентом, также создает поды с соответствующими сервисами для других компонентов платформы:
- postgres, реализующий СУБД PostgreSQL, использует ресурс PVC (Persistent Volume Claim) для запроса дискового пространства в виде постоянного тома (PV, не показан на схеме). В этом томе он создает СУБД, которую используют все компоненты платформы (Platform Gateway, Automation Controller, Private Automation Hub и контроллер EDA) для создания собственных баз данных и управления ими. Доступ к базам данных обеспечивают контроллеры service в среде Kubernetes.
- redis, реализующий кеш для Platform Gateway и контроллера EDA, запрашивает дисковое пространство через PVC. Полученный том он использует в качестве надежного хранилища, обеспечивающего восстановление данных в случае пересоздания пода. Доступ к данным обеспечивает контроллер service.
Automation Controller – плоскость управления (control plane):
- web и соответствующий service обрабатывают входные запросы от веб-интерфейса и API. Они также обеспечивают интеграцию с другими компонентами платформы и внешними ресурсами. Внутри пода реализован Redis для обмена данными в пределах контроллера.
- Для выполнения заданий выделен отдельный task pod.
Private Automation Hub – реестр инфраструктурного кода, реализованный с помощью набора компонентов:
- web и соответствующий service принимают запросы от веб-интерфейса и API и выполняют их первичную обработку.
- api обрабатывает запросы REST API.
- worker обрабатывает фоновые задачи и асинхронные операции.
- resource manager управляет ресурсами и их распределением.
- redis обеспечивает кеширование промежуточных данных.
- content управляет контентом, включая коллекций Ansible и артефакты в виде образов среды исполнения и среды принятия решений. Он обеспечивает хранение контента в файловой системе отдельного хранилища.
- Content storage – хранилище контента. Выбор устройства хранения зависит от того, планируете ли вы развивать платформу в дальнейшем, увеличивая количество узлов приватного реестра. Если нет, то можно использовать PV. Если планируете, то следует выбирать хранилище, которое обеспечивает доступ к нему со стороны нескольких узлов в режиме чтения-записи (RWX, ReadWriteMany). Не все облачные системы, предоставляющие сервис Managed Kubernetes, обеспечивают это. Поэтому в общем случае рекомендуется использовать внешнее хранилище в виде S3, которое обеспечивает такой режим.
Event-Driven Automation – сервис, отслеживающий события в инфраструктуре и инициирующий автоматические сценарии. Он реализуется в виде следующих компонентов:
- api обеспечивает обработку запросов от Platform Gateway по протоколу HTTP/HTTPS.
- activation управляет активациями правил по обработке событий.
- worker обрабатывает фоновые задачи и асинхронные операции с помощью среды принятия решений (DE).
- stream обеспечивает связь с внешними источниками событий типа Kafka, Webhook и другие.
- scheduler планирует обработку событий с помощью других компонентов, перечисленных ранее, в определенной последовательности. В его обязанности входят также формирование и посылка запросов на выполнение заданий в Automation Controller, управление очередями событий в Redis и хранение состояния активаций и истории выполнения заданий в базе данных.

К центральным компонентам добавляется сеть Mesh с делением системы автоматизации на две плоскости: плоскость управления (Automation Controller, Control Plane) и плоскость исполнения (Execution Plane). Последняя содержит исполняющие узлы (Execution nodes) для создания распределенной системы управления в соответствии с топологией инфраструктуры, подлежащей автоматизации. Появляется дополнительное сетевое соединение через сеть Mesh, которое обеспечивает взаимодействие между управляющим и исполняющими узлами с помощью службы рецепторов. Необходима настройка сетевых фильтров на связь по порту TCP 27199 для взаимодействия рецепторов. При необходимости в топологию можно добавить переходные узлы (hop nodes) для маршрутизации трафика и обеспечения связи с исполняющими узлами, расположенными в сложных или изолированных сетевых сегментах.

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

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

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

../../_images/aa-k8s-enterprise-light.svg

../../_images/aa-k8s-enterprise-dark.svg

По сравнению с базовой топологией уровень предприятия добавляет множество ресурсов и возможностей Kubernetes:

Три или более рабочих узлов (worker nodes) необходимы для обеспечения доступности компонентов платформы в случае выхода из строя одного из них.
Развитая масштабируемая сеть Mesh обеспечивает необходимую производительность и надежность процессов автоматизации для сетей практически любой сложности. Для обеспечения лучшей масштабируемости добавлен промежуточный узел Automation Mesh Ingress (hop node), который принимает запросы от исполняющих узлов (execution nodes) на установление соединения с Automation Controller посредством сервиса receptor. Таким образом обеспечивается возможность установления соединений по инициативе контроллера (от task pod) или по инициативе исполняющих узлов.
Для еще более высокой устойчивости рекомендуется центральную часть платформы, реализуемую через Kubernetes, развертывать на рабочих узлах, распределенных географически. В облачных сервисах Managed Kubernetes это обеспечивается использованием двух и более зон доступности.
Базы данных компонентов платформы необходимо создавать с использованием корпоративного кластера СУБД PostgreSQL, обеспечивающего его высокую доступность по определенному IP-адресу и порту TCP.
Служба Ingress в Kubernetes обеспечивает балансировку нагрузки. При географически распределенном кластере Kubernetes необходим внешний балансировщик нагрузки для Platform Gateway, например на основе HAProxy Load Balancer.

Операторы Kubernetes для Astra Automation#

Развертывание платформы в среде Kubernetes осуществляется с помощью операторов Astra Automation. В соответствии с функциональным делением платформы на компоненты используются следующие операторы:

aa-operator-aa-manager является корневым оператором, управляющим шлюзом платформы (Platform Gateway) и общими компонентами – Redis и PostgreSQL.
ac-operator-ac-manager управляет Automation Controller.
pah-operator-pah-manager управляет Private Automation Hub и хранилищем контента.
eda-operator-eda-manager управляет контроллером Event-Driven Automation.

Название оператора определяется в его манифесте (см. пояснение далее) через название основного компонента, которым обычно является Deployment или StatefulSet. В определении основного компонента это будет поле metadata.name.

Принцип действия#

Оператор Kubernetes – это постоянная вспомогательная служба, которая обслуживает жизненный цикл приложения, включая его создание, периодические обновления и удаление. Для развертывания оператора используют файл настроек (манифест) в формате YAML, который содержит как описание компонентов самого оператора (различные поды, сервисы поверх них и др.), так и определение ресурсов приложения – CRD (Custom Resource Definition).

Примечание

Манифест оператора является универсальным для всех рассмотренных ранее вариантов топологии платформы Astra Automation.

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

Установка оператора с помощью его манифеста.
Подготовка манифеста для развертывания приложения через оператор.
Развертывание приложения с помощью манифеста, в котором используются ресурсы оператора. Приложение базируется на собственных типах ресурсов (CR, Custom Resource), определенных через CRD оператора. На этом шаге вы определяете необходимую вам топологию платформы.
Поддержка жизненного цикла приложения:
- мониторинг состояния и нагрузки компонентов приложения;
- автоматическое поддержание компонентов приложения в рабочем состоянии;
- обновление приложения по запросу.
Удаление приложения.

Пример#

Рассмотрим структуру установленного оператора и управляемого им приложения на примере Automation Controller.

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

Компоненты оператора#

После развертывания оператор находится в режиме ожидания запросов от сотрудников, управляющих жизненным циклом платформы. В рабочем состоянии находятся следующие компоненты в пространстве astra-automation:

AC Operator deployment – менеджер оператора ac-operator-ac-manager. Это основной компонент оператора, базирующийся на следующих контейнерах:
- ac-operator-ac-manager – контейнер, реализующий основную логику оператора;
- kube-rbac-proxy – сопровождающий (sidecar) контейнер для проксирования метрик, доступ к которому обеспечивает ролевая система управления (RBAC, Role-Based Access Control).
Остальные объекты предназначены для обслуживания этого ресурса.
ServiceAccount – сервисная учетная запись для идентификации менеджера при его взаимодействии с Kubernetes.
Roles & RoleBindings – роли типа ClusterRole и привязка их к сервисной учетной записи (тип RoleBinding), обеспечивающие необходимые привилегии для менеджера в Kubernetes.
ConfigMap – настройки менеджера (ac-operator-ac-manager-config).
Metrics Service – сервис для экспорта метрик, доступный по порту TCP 8443.

В манифесте оператора определены четыре специальных ресурса приложения (CRD) в группе ac.astra-automation.ru:

AutomationController (acs.ac.astra-automation.ru/v1beta1) – основной ресурс для развертывания управляющего узла Automation Controller.
AutomationControllerBackup (acbackups.ac.astra-automation.ru/v1beta1) – ресурс для создания резервных копий контроллера.
AutomationControllerRestore (acrestores.ac.astra-automation.ru/v1beta1) – ресурс для восстановления контроллера из резервной копии.
AutomationControllerMeshIngress (acmeshingresses.ac.astra-automation.ru/v1alpha1) – ресурс для настройки сетевого доступа через сервис Mesh.

Примечание

На текущий момент этот ресурс не поддерживается. Связь с сетью Mesh осуществляется через task pod в Automation Controller.

Каждое описание CRD определяет комплексную архитектуру, состоящую из множества объектов Kubernetes.

Компоненты приложения#

При создании приложения AutomationController необходимо в среде Kubernetes исполнить манифест, требующий создания ресурсов, описанных в CRD оператора. В манифесте указывают значения параметров, которые необходимы для реализации требуемой топологии. Если они не указаны, используются значения по умолчанию. Оператор автоматически создает требуемые компоненты приложения, которые в представленной ранее схеме заданы обобщенно без подробностей реализации. Более подробно каждый компонент Astra Automation представлен в описании топологии.

Основные компоненты (Core Components) приложения:

Web Deployment – объекты веб-интерфейса Automation Controller;
Task Deployment – под для выполнения задач;
PostgreSQL StatefulSet – объекты для доступа к базе данных PostgreSQL;
Redis Deployment – объекты обеспечения работы Redis;
Execution Environments (EE) – среда исполнения заданий автоматизации.

Средства хранения данных (Storage):

PostgreSQL PVC – запрос на предоставление постоянного хранилища для базы данных;
Projects PVC (optional) – запрос на предоставление постоянного хранилища для проектов автоматизации;
Backup PVC – запрос на предоставление постоянного хранилища для резервных копий.

Сетевые компоненты (Networking):

Services – сервисы различного типа для доступа к компонентам контроллера:
- внутри кластера Kubernetes с помощью приватных адресов (ClusterIP);
- извне через IP-адрес рабочего узла кластера и порт TCP, выделенный для конкретного сервиса (NodePort);
- извне через выделенный публичный IP-адрес (LoadBalancer);
Ingress/Route – внешний доступ к объединенному интерфейсу;

Настройки (Configuration) в виде подключаемых томов:

ConfigMaps – настройка приложения в виде параметров типа ключ-данные;
Secrets – секреты для паролей, ключей и сертификатов;
ServiceAccounts – сервисные учетные записи для компонентов.

Дополнительные компоненты (Optional Components):

Metrics Utility CronJobs – запланированные задания для сбора метрик по расписанию;
Init Containers – служебные контейнеры для подготовки к запуску основных контейнеров;
Syslog-ng Container - контейнер для централизованного ведения журналов.