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

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

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

../../../_images/day1-lb-green.svg ../../../_images/day1-deploy-blue.svg ../../../_images/day1-subscription-white.svg ../../../_images/day1-test-white.svg ../../../_images/day1-lb-green.svg ../../../_images/day1-deploy-blue.svg ../../../_images/day1-subscription-dark.svg ../../../_images/day1-test-dark.svg

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

Ресурс

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

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

Рабочая станция

Утилиты kubectl, ansible-navigator

Утилиты kubectl, ansible-navigator

Кластер Kubernetes

С одним рабочим узлом

С тремя рабочими узлами

Сетевое хранилище для Private Automation Hub

Требования

Требования

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

Требования

Требования

Плоскость исполнения

Исполняющий узел

Плоскость исполнения

СУБД

Будет создана при развертывании Astra Automation

Внешняя СУБД

Манифесты секретов
- Доступ к шлюзу по HTTPS
- Пароль для доступа к шлюзу
- Доступ к внешнему хранилищу контента
- Доступ к шлюзу по HTTPS
- Пароль для доступа к шлюзу
- Доступ к внешнему хранилищу контента
- Ключи шифрования данных в базах
- Доступ к базам данных

Манифест приложения

Пример

Пример

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

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

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

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

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

  1. Добавьте пакет Ingress в индексную базу Helm:

    helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

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

    "ingress-nginx" has been added to your repositories

  2. Обновите репозиторий Helm:

    helm repo update

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

    ...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈

    Примечание

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

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

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

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

    Installation output
    NAME: ingress-nginx
LAST DEPLOYED: Tue Oct 14 11:33:56 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the load balancer IP to be available.
You can watch the status by running 'kubectl get service --namespace default ingress-nginx-controller --output wide --watch'

An example Ingress that makes use of the controller:
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 80
              path: /
    # This section is only required if TLS is to be enabled for the Ingress
    tls:
      - hosts:
        - www.example.com
        secretName: example-tls

If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
    tls.crt: <base64 encoded cert>
    tls.key: <base64 encoded key>
  type: kubernetes.io/tls

  4. Настройте сервис Ingress на возможность установления соединения через WebSocket между сервисами receptor на внешних исполняющих узлах (execution nodes) и внутренними переходными узлами (hop nodes), не терминируя соединения, использующие TLS:

    helm upgrade ingress-nginx ingress-nginx/ingress-nginx --set controller.extraArgs.enable-ssl-passthrough=true

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

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

kubectl apply -f operators/

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

Installation output
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

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

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

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

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

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

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

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

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

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

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

kubectl logs -n astra-automation aa-operator-aa-manager-76d84985d9-bpll6 -c manager

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

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

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

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

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

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

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

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

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

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

  1. Задайте количество реплик, например 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

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

    kubectl -n astra-automation get deployments

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

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

    где <path/to/secret.yaml> – путь к файлу, содержащему манифест соответствующих секретов в формате YAML.

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

    • доступ к хранилищу S3 для Private Automation Hub;

    • доступы к базам данных PosgreSQL для всех компонентов платформы;

    • секреты для шифрования чувствительных данных в базах данных;

    • пароль администратора платформы;

    • параметры TLS для защиты данных, передаваемых по сети;

  3. Запустите процесс развертывания платформы:

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

    где <path/to/application-manifest.yml> – путь к файлу, содержащему манифест приложения.

  4. Если необходимо обеспечить возможность установления соединений от исполняющих узлов к 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.

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

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

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

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

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

  2. Используйте полное название пода aa-operator-aa-manager для просмотра журнала выполнения сценария развертывания:

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

    Аргумент -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

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

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

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

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

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