Развертывание в кластере Kubernetes

Содержание

Развертывание в кластере Kubernetes#

На этой стадии происходит развертывание платформы в кластере Kubernetes.

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

Ресурс	Базовая топология	Топология уровня предприятия
Рабочая станция	Утилиты `kubectl`, `ansible-navigator`	Утилиты `kubectl`, `ansible-navigator`
Кластер Kubernetes	С одним рабочим узлом	С тремя рабочими узлами
Сетевое хранилище для Private Automation Hub	Требования	Требования
Настройка сетевых фильтров	Требования	Требования
Плоскость исполнения	Исполняющий узел	Плоскость исполнения
СУБД	Будет создана при развертывании Astra Automation	Внешняя СУБД
Манифесты секретов	- Доступ к шлюзу по HTTPS - Пароль для доступа к шлюзу - Доступ к внешнему хранилищу контента	- Доступ к шлюзу по HTTPS - Пароль для доступа к шлюзу - Доступ к внешнему хранилищу контента - Ключи шифрования данных в базах - Доступ к базам данных
Манифест приложения	Пример	Пример

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

Предупреждение

Если процесс Reconciliation операторов начнется до завершения загрузки образов, Kubernetes не сможет создать поды компонентов платформы, что приведет к ошибкам вида ImagePullBackOff или ErrImageNeverPull.

Установка контроллера Ingress#

Если отсутствует контроллер Ingress, установите его с помощью менеджера пакетов Helm:

Добавьте пакет Ingress в индексную базу Helm:
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
```
Информационное сообщение от команды:
```
"ingress-nginx" has been added to your repositories
```
Обновите репозиторий Helm:
```
helm repo update
```
Информационное сообщение от команды:
```
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈
```
Примечание

Обе предыдущие команды выполняют настройку на рабочей станции, где используется утилита helm. Поэтому, если по какой-либо причине потребуется повторить развертывание, можно эти шаги пропустить.

Установите сервис Ingress в Kubernetes:

helm install ingress-nginx ingress-nginx/ingress-nginx

Информационное сообщение от команды:

Настройте сервис Ingress на возможность установления соединения через WebSocket между сервисами receptor на внешних исполняющих узлах (execution nodes) и внутренними переходными узлами (hop nodes), не терминируя соединения, использующие TLS:
```
helm upgrade ingress-nginx ingress-nginx/ingress-nginx --reuse-values --set controller.extraArgs.enable-ssl-passthrough=true
```

Ограничения на загрузку образов среды исполнения#

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

proxy-body-size – предельно допустимый объем тела запроса, по умолчанию 1 МБ. При его превышении загрузка завершается ошибкой 413 Request Entity Too Large.
proxy-read-timeout и proxy-send-timeout – предельно допустимое время ожидания при обмене данными с сервером, по умолчанию 60 секунд каждый. Передача одного слоя крупного образа может занять больше времени, и тогда загрузка завершается ошибкой 504 Gateway Timeout.

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

helm upgrade ingress-nginx ingress-nginx/ingress-nginx --reuse-values \
--set controller.config.proxy-body-size=3g \
--set controller.config.proxy-read-timeout=300 \
--set controller.config.proxy-send-timeout=300

Значение 3g покрывает образы среды исполнения, поставляемые с Astra Automation 2.1. При использовании собственных образов большего объема его необходимо увеличить. Значения таймаутов заданы в секундах, и 300 секунд с запасом перекрывают паузы при передаче слоя крупного образа.

Примечание

Параметр --reuse-values сохраняет параметры, заданные ранее. Без него команда вернет остальные параметры контроллера Ingress к значениям по умолчанию, в том числе отключит режим SSL passthrough. Поэтому он указан в обеих командах helm upgrade (при включении режима SSL passthrough и при снятии ограничений), и их можно выполнять в любом порядке.

Команда настраивает контроллер Ingress целиком, поэтому ее можно выполнить как сразу после установки контроллера, так и на уже работающем контроллере – до развертывания платформы.

Если платформа уже развернута, те же ограничения можно снять точечно, для ее ресурса ingress:

kubectl annotate ingress aa-demo -n astra-automation \
"nginx.ingress.kubernetes.io/proxy-body-size=3g" \
"nginx.ingress.kubernetes.io/proxy-read-timeout=300" \
"nginx.ingress.kubernetes.io/proxy-send-timeout=300" --overwrite

Здесь:

aa-demo – название приложения, указанное в манифесте приложения;
astra-automation – пространство имен, в котором развернута платформа.

Примечание

На тестовом стенде ограничение на объем можно снять полностью, задав proxy-body-size=0. В продуктовой среде так делать нельзя: без этого ограничения одним запросом можно исчерпать ресурсы узла.

Установка операторов#

Установите все операторы Astra Automation:

kubectl apply -f operators/

Информационное сообщение от команды:

Вывод команды установки

namespace/astra-automation created
customresourcedefinition.apiextensions.k8s.io/aabackups.aa.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/aarestores.aa.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/aas.aa.astra-automation.ru created
serviceaccount/aa-operator-aa-manager created
role.rbac.authorization.k8s.io/aa-operator-leader-election-role created
role.rbac.authorization.k8s.io/aa-operator-manager-role created
clusterrole.rbac.authorization.k8s.io/aa-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/aa-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/aa-operator-leader-election-rolebinding created
rolebinding.rbac.authorization.k8s.io/aa-operator-manager-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/aa-operator-proxy-rolebinding created
service/aa-operator-aa-manager-metrics-service created
deployment.apps/aa-operator-aa-manager created
namespace/astra-automation configured
customresourcedefinition.apiextensions.k8s.io/acbackups.ac.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/acmeshingresses.ac.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/acrestores.ac.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/acs.ac.astra-automation.ru created
serviceaccount/ac-operator-ac-manager created
role.rbac.authorization.k8s.io/ac-operator-ac-manager-role created
role.rbac.authorization.k8s.io/ac-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/ac-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/ac-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/ac-operator-ac-manager-rolebinding created
rolebinding.rbac.authorization.k8s.io/ac-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/ac-operator-proxy-rolebinding created
configmap/ac-operator-ac-manager-config created
service/ac-operator-automationcontroller-manager-metrics-service created
deployment.apps/ac-operator-ac-manager created
namespace/astra-automation configured
customresourcedefinition.apiextensions.k8s.io/pahbackups.pah.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/pahrestores.pah.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/pahs.pah.astra-automation.ru created
serviceaccount/pah-operator-sa created
role.rbac.authorization.k8s.io/pah-operator-leader-election-role created
role.rbac.authorization.k8s.io/pah-operator-pah-operator-role created
role.rbac.authorization.k8s.io/pah-operator-proxy-role created
clusterrole.rbac.authorization.k8s.io/pah-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/pah-operator-pah-operator-cluster-role created
rolebinding.rbac.authorization.k8s.io/pah-operator-leader-election-rolebinding created
rolebinding.rbac.authorization.k8s.io/pah-operator-pah-operator-rolebinding created
rolebinding.rbac.authorization.k8s.io/pah-operator-proxy-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/pah-operator-pah-operator-cluster-rolebinding created
configmap/pah-operator-pah-operator-config created
service/pah-operator-pah-manager-metrics-service created
deployment.apps/pah-operator-pah-manager created
namespace/astra-automation configured
customresourcedefinition.apiextensions.k8s.io/edabackups.eda.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/edarestores.eda.astra-automation.ru created
customresourcedefinition.apiextensions.k8s.io/edas.eda.astra-automation.ru created
serviceaccount/eda-operator-eda-manager created
role.rbac.authorization.k8s.io/eda-operator-eda-manager-role created
role.rbac.authorization.k8s.io/eda-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/eda-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/eda-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/eda-operator-eda-manager-rolebinding created
rolebinding.rbac.authorization.k8s.io/eda-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/eda-operator-proxy-rolebinding created
service/eda-operator-eda-manager-metrics-service created
deployment.apps/eda-operator-eda-manager created

Команда создает новое пространство имен – astra-automation – с операторами внутри него. В этом пространстве будут создаваться все объекты центральной части платформы. Проверьте готовность подов:

kubectl -n astra-automation get pods

Они должны быть в состоянии Running:

NAME                                                         READY   STATUS    RESTARTS   AGE
aa-operator-aa-manager-76d84985d9-bpll6                      2/2     Running   0          2m19s
ac-operator-ac-manager-748f66f8b8-jnf4x                      2/2     Running   0          2m16s
eda-operator-eda-manager-644b75748d-7dlzr                    2/2     Running   0          2m11s
pah-operator-pah-manager-68c859659b-6jsv4                    2/2     Running   0          2m14s
dashboard-operator-dashboard-manager-6c8f8f7c9b-v2q5n        2/2     Running   0          2m09s

Создание секретов#

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

kubectl apply -f <path/to/file.yml>

Здесь <path/to/file.yml> – путь к файлу с манифестом. Например:

TLS

kubectl apply -f /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/k8s-enterprise-aa-demo-tls-secrets.yaml

Доступ к S3

kubectl apply -f /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/k8s-enterprise-aa-demo-s3-secrets.yaml

Доступ к БД

kubectl apply -f /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/k8s-enterprise-aa-demo-pg-secrets.yaml

Шифрование

kubectl apply -f /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/k8s-enterprise-aa-demo-encryption-secrets.yaml

Доступ к шлюзу

kubectl apply -f /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/k8s-enterprise-aa-demo-password-secrets.yaml

Развертывание базовой топологии Astra Automation#

Развертывание базовой топологии состоит из следующих этапов.

Развертывание центральных компонентов#

Для развертывания центральной части необходимо применить ранее подготовленный манифест:

kubectl apply -f <path/to/manifest.yml>

Если в манифесте есть блок spec.dashboard, операторы развернут Automation Dashboard вместе с платформой и опубликуют его через Ingress по пути /dashboard. Если средства аналитики не требуются, не добавляйте этот блок. Инструкция по добавлению Automation Dashboard к уже развернутой платформе приведена в отдельной инструкции.

Процесс может занять около 20 минут. Окончание развертывания проверяйте по журналу:

kubectl logs -n astra-automation <aa-operator-aa-manager full name> -c manager --timestamps

Завершение обозначено заключительной секцией как при обычном выполнении набора сценариев Ansible.

Первичная настройка#

Проверьте с помощью браузера, что можно подключиться к шлюзу, используя URL https://<ip or domain.name>, по его IP-адресу или доменному имени и пройти аутентификацию с учетной записью администратора.

После этого активируйте подписку, чтобы перейти в панель управления Astra Automation. Затем проверьте состав созданных сред исполнения и принятия решений.

Важно

Если PostgreSQL развернута средствами платформы из образа, выпущенного до версии 2.1, беспарольный доступ по TCP необходимо закрыть сразу после развертывания, так как файл pg_hba.conf в таких образах разрешает беспарольное подключение любой ролью. При развертывании из образа версии 2.1 и более поздних проверьте, что подключение по TCP требует пароля. Порядок проверки и устранения приведен в инструкции по закрытию беспарольного доступа к PostgreSQL.

Добавление исполняющего узла#

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

Развертывание топологии уровня предприятия#

Процесс состоит из следующих стадий.

Развертывание центральной части#

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

Задайте количество реплик, например 3, для каждого установленного оператора:

kubectl scale deployment aa-operator-aa-manager --namespace astra-automation --replicas=3
kubectl scale deployment ac-operator-ac-manager --namespace astra-automation --replicas=3
kubectl scale deployment eda-operator-eda-manager --namespace astra-automation --replicas=3
kubectl scale deployment pah-operator-pah-manager --namespace astra-automation --replicas=3
kubectl scale deployment dashboard-operator-dashboard-manager --namespace astra-automation --replicas=3

После выполнения команд каждый объект deployment должен содержать три реплики:

kubectl -n astra-automation get deployments

Убедитесь, что на стадии подготовки файлы с манифестами секретов настроены в соответствии с рекомендациями, и примените каждый из них с помощью команды вида:
```
kubectl apply -f <path/to/secret.yml>
```
Здесь <path/to/secret.yml> – путь к файлу, содержащему манифест соответствующих секретов в формате YAML.

Должны быть подготовлены файлы с манифестами для следующих секретов:
- доступ к хранилищу S3 для Private Automation Hub;
- доступы к базам данных PostgreSQL для всех компонентов платформы;
- секреты для шифрования чувствительных данных в базах данных;
- пароль администратора платформы;
- параметры TLS для защиты данных, передаваемых по сети.
Запустите процесс развертывания платформы:
```
kubectl apply -f <path/to/application-manifest.yml>
```
Здесь <path/to/application-manifest.yml> – путь к файлу, содержащему манифест приложения.
Если необходимо обеспечить возможность установления соединений от исполняющих узлов к Automation Controller, добавьте объекты Mesh Ingress, каждый из которых представляет переходный узел (hop node). В зависимости от того, собраны ли манифесты в одном файле или подготовлено несколько файлов, выполните одну или несколько команд вида:
```
kubectl apply -f <path/to/mesh-ingress.yml>
```
Здесь <path/to/mesh-ingress.yml> – путь к файлу, содержащему манифест ресурса AutomationControllerMeshIngress.

Контроль процесса развертывания#

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

watch -n 5 "kubectl get aas aa-demo -n astra-automation -o jsonpath='{.status.conditions}'"

Здесь aa-demo – название приложения, указанное в манифесте приложения.

Выход из команды производится с помощью комбинации клавиш Ctrl+C.

При установленной утилите jq можно получить более удобный формат вывода:

watch -n 5 "kubectl get aas aa-demo -n astra-automation -o jsonpath='{.status.conditions}' | jq "

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

[
   {
      "lastTransitionTime": "2025-10-27T14:45:52Z",
      "message": "",
      "reason": "",
      "status": "False",
      "type": "Failure"
   },
   {
      "lastTransitionTime": "2025-10-27T14:45:52Z",
      "message": "Last reconciliation succeeded",
      "reason": "Successful",
      "status": "True",
      "type": "Successful"
   },
   {
      "lastTransitionTime": "2025-10-27T14:45:52Z",
      "message": "Awaiting next reconciliation",
      "reason": "Successful",
      "status": "True",
      "type": "Running"
   }
]

Ключевые моменты:

В секции, где "type": "Failure", поле message пустое.
В секции, где "type": "Successful", поле message содержит сообщение Last reconciliation succeeded.
В секции, где "type": "Running", поле message содержит сообщение Awaiting next reconciliation.

Если манифест приложения содержит блок spec.dashboard, дополнительно проверьте состояние ресурса Dashboard:

kubectl -n astra-automation get dashboards

Операторы должны создать ресурс Dashboard, а связанные с ним поды должны перейти в состояние Running.

Для более подробной информации рекомендуется изучить журнал выполнения сценария развертывания, предварительно узнав полное название пода aa-operator-aa-manager.

Узнайте полное название пода aa-operator-aa-manager:

kubectl get pods -n astra-automation | grep aa-operator

Выходные данные имеют следующий вид:

aa-operator-aa-manager-76d84985d9-hmswf     2/2     Running   0          6m33s

Используйте полное название пода aa-operator-aa-manager для просмотра журнала выполнения сценария развертывания:
```
kubectl logs -n astra-automation -f <aa-operator-aa-manager full name> -c manager --timestamps
```
Аргумент -f требует постоянного обновления данных, полученных из журнала.

Журнал показывает ход выполнения сценария и возникающие ошибки. Итоговый вывод PLAY RECAP сообщает об успешном или неудачном завершении сценария. Продукт полностью развернут при успешном выполнении сценария и PLAY RECAP с полем failed=0 вида:

{"level":"info","ts":"2025-10-21T11:10:20Z","logger":"runner","msg":"Ansible-runner exited successfully","job":"182878699511911518","name":"aa-demo","namespace":"astra-automation"}

----- Ansible Task Status Event StdOut (aa.astra-automation.ru/v1alpha1, Kind=AstraAutomation, aa-demo/astra-automation) -----

PLAY RECAP *********************************************************************
localhost                  : ok=195  changed=2    unreachable=0    failed=0    skipped=103  rescued=0    ignored=0

Известная проблема: ошибка CreateContainerError, поды Event-Driven Automation не созданы#

Если поды Event-Driven Automation остаются в состоянии CreateContainerError с сообщением string field contains invalid UTF-8, секрет с ключом шифрования Event-Driven Automation содержит двоичное значение.

Проблема возникает, если секреты с ключами шифрования созданы вручную по примеру манифеста, в котором вывод команды openssl rand -base64 32 помещен в секцию data. Kubernetes декодирует содержимое секции data и передает полученное значение в под, поэтому фактическим ключом становится набор двоичных данных вместо текстовой строки. Event-Driven Automation получает ключ через переменную окружения, а containerd версии 2.0 и выше не допускает двоичные значения таких переменных. Пример манифеста в этом руководстве использует секцию stringData и к проблеме не приводит, см. секреты для шифрования. В комплекте поставки 2.0-upd2 пример остается прежним, поэтому созданные по нему секреты необходимо проверить.

В базовой топологии проблема не возникает, так как ключи шифрования генерируются операторами автоматически. С containerd версии 1.7 и ниже поды запускаются нормально, поэтому проблема может проявиться не сразу: как при новой установке в кластере с containerd версии 2.0 и выше, так и после обновления узлов работающего кластера до этой версии. Если кластер работает на containerd версии 1.7 и ниже, проверку и, при необходимости, приведение секрета к каноничной форме рекомендуется выполнить до планового обновления узлов кластера: после обновления поды Event-Driven Automation не запустятся.

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

if ! RAW=$(kubectl -n astra-automation get secret eda-encryption-secret -o jsonpath='{.data.secret_key}') || [ -z "$RAW" ]; then
   echo ERROR
elif printf '%s' "$RAW" | base64 -d | iconv -f utf-8 -t utf-8 >/dev/null 2>&1; then
   echo OK
else
   echo BINARY
fi

Ожидаемый результат: OK. Если команда возвращает BINARY, секрет eda-encryption-secret содержит двоичный ключ. Если команда возвращает ERROR, значение секрета не прочитано и состояние ключа неизвестно: проверьте доступность кластера, название пространства имен и наличие в нем секрета eda-encryption-secret, затем повторите проверку.

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

Получите каноничную форму фактически используемого ключа:
```
set -o pipefail

NEW_B64=$(kubectl -n astra-automation get secret eda-encryption-secret -o jsonpath='{.data.secret_key}' \
   | base64 -d \
   | python3 -c "import sys,base64; print(base64.b64encode(sys.stdin.buffer.read().decode('utf-8','replace').encode()).decode())")
```
Команда set -o pipefail необходима, чтобы ошибка чтения секрета не осталась незамеченной из-за успешного завершения последующих команд конвейера. Если секрет не прочитан, переменная NEW_B64 остается пустой.
Замените значение секрета:
```
if [ -n "$NEW_B64" ]; then
   kubectl -n astra-automation patch secret eda-encryption-secret --type merge \
      -p "{\"data\":{\"secret_key\":\"$NEW_B64\"}}"
else
   echo "Каноничная форма ключа не получена, секрет не изменен"
fi
```
Проверка непустого значения обязательна: запись пустого значения в secret_key сделает ранее зашифрованные данные нечитаемыми. Если выведено сообщение о неполученной каноничной форме, вернитесь к предыдущему действию и устраните ошибку чтения секрета.
Перезапустите компоненты Event-Driven Automation:
```
kubectl -n astra-automation rollout restart deploy \
   -l "app.kubernetes.io/managed-by=eda-operator,app.kubernetes.io/name=<eda-cr>"
```
Здесь:
- <eda-cr> – название пользовательского ресурса Event-Driven Automation в кластере.

Ранее зашифрованные данные остаются доступными, реквизиты доступа и токены пересоздавать не требуется. Секреты ac-encryption-secret и aa-encryption-secret изменять не требуется: их значения не передаются через переменные окружения.

Активация лицензии#

С помощью браузера обратитесь по URL, настроенному в манифесте приложения, например https://aa.demo.example.com/. Активируйте лицензию подписки. Затем проверьте состав созданных сред исполнения и принятия решений.

Добавление плоскости исполнения#

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

Добавление может быть выполнено одним из способов, приведенных в описании операционных задач.

Проверка сред исполнения и принятия решений#

При развертывании платформы операторы регистрируют в Automation Controller две среды исполнения, а в компоненте Event-Driven Automation – одну среду принятия решений. Состав записей не зависит от наличия доступа в интернет; различается только реестр, из которого загружаются образы:

Название	Образ при развертывании с доступом в интернет	Образ при развертывании без доступа в интернет
Control Plane Execution Environment	`hub.astra-automation.ru/aa-2.1/aa-control-ee:latest`	`<gateway_fqdn>/aa-2.1/aa-control-ee:latest`
Default execution environment	`hub.astra-automation.ru/aa-2.1/aa-full-ee:latest`	`<gateway_fqdn>/aa-2.1/aa-full-ee:latest`
Default Decision Environment	`hub.astra-automation.ru/aa-2.1/aa-full-de:latest`	`<gateway_fqdn>/aa-2.1/aa-full-de:latest`

Здесь <gateway_fqdn> – доменное имя шлюза платформы, заданное в параметре hostname манифеста приложения.

При развертывании без доступа в интернет Automation Controller и Event-Driven Automation загружают образы из Private Automation Hub через шлюз: импортер контента помещает образы в пространство имен aa-2.1 в Private Automation Hub. Назначение обеих сред исполнения приведено в описании сред исполнения контроллера.

Для проверки состава записей выполните следующие действия:

На панели навигации выберите Автоматизация процессов ‣ Инфраструктура ‣ Среды исполнения (Automation Execution ‣ Infrastructure ‣ Execution Environments) и убедитесь, что созданы записи «Control Plane Execution Environment» и «Default execution environment» с образами из таблицы.
На панели навигации выберите Обработка событий ‣ Среды принятия решений (Automation Decisions ‣ Decision Environments) и убедитесь, что создана запись «Default Decision Environment» с образом из таблицы.

Примечание

Запись «Control Plane Execution Environment» указывает на образ в реестре из таблицы. Однако служебные контейнеры плоскости управления – контейнер awx-ee пода контроллера, init-контейнеры и переходные узлы Mesh Ingress – используют образ из комплекта поставки, заданный параметром control_plane_ee_image манифеста приложения: под контроллера запускается раньше, чем импортер контента наполняет Private Automation Hub. При развертывании без доступа в интернет этот образ предварительно загружен в containerd на рабочих узлах.

Важно

Из-за тега latest поды заданий создаются с политикой imagePullPolicy: Always: при каждом запуске задания Kubernetes обращается к реестру за образом (повторно загружаются только отсутствующие слои). Поэтому при развертывании с доступом в интернет для запуска заданий необходим постоянный доступ рабочих узлов Kubernetes к реестру hub.astra-automation.ru. При недоступности реестра задания не запускаются, даже если образ уже загружен на узел.