Модуль программного управления Платформой (shturval-backend)

О сервисе #

Сервис входит в Helm chart shturval-backend. Этот chart также разворачивает оператор согласования прав (stp-controller), который отдаёт bundle для OPA. Компоненты аутентификации и сессий находятся в chart shturval-auth.

Содержание #

1. Обзор
2. Архитектура
3. Установка / развёртывание
4. Диагностика
5. Жизненный цикл
6. Параметры сервиса

1. Обзор #

Назначение: главный программный интерфейс управления платформой через HTTP API (/api/v1): кластеры, группы узлов и провайдеры (семейство CAP*), объектные ресурсы namespace/workload при необходимости, терминалы и журналы, метрики, интеграция с авторизационным контуром и внешними точками по конфигурации. Изменение состояния кластера происходит по запросам оператора/API-клиента, а не через согласование CR собственными reconciler-ами внутри процесса.

Функции #

Сценарии инициации #

Ограничения и следствия #

Место в цепочке управления #

Потребитель отправляет HTTPS-запрос в pod backend: трафик сначала обрабатывает Envoy, который проксирует его на локальный процесс sh-backend-api на 127.0.0.1:8080. Параллельно сайдкар OPA проверяет политики авторизации по bundle прав. Сам процесс API обращается к Kubernetes API для чтения и изменения объектов и к внешним URL партнёрских компонентов: authn-server, session-manager, ldap-cache и др.

Связанные компоненты #

Ключевые характеристики #

2. Архитектура #

Компоненты рабочей нагрузки #

RBAC процесса в кластере определяется манифестами chart shturval-backend; перечень прав точечно здесь не дублируется.

3. Установка / развёртывание #

Развёртывание задаётся Helm chart shturval-backend. Компоненты API, Envoy, OPA, Swagger UI, permissions operator и сопряжённые объекты (RBAC, Service, Ingress/Envoy конфигурация) создаются единым релизом.

Обратите внимание! любые изменения параметров установки должны выполняться согласованно с платформой через ShturvalServicePatch (SSP) (или эквивалентный утверждённый механизм), без ручных правок в обход управления платформы.

4. Диагностика #

Типовые проверки следующие (NAMESPACE, DEPLOYMENT, POD подставьте по фактической установке; имени Deployment соответствуют значения Helm chart shturval-backend):

kubectl get deployment -n "${NAMESPACE}"
kubectl get pods -n "${NAMESPACE}" -o wide
kubectl describe pod -n "${NAMESPACE}" "${POD}"
kubectl logs -n "${NAMESPACE}" "${POD}" -c sh-backend-api --tail=200
kubectl logs -n "${NAMESPACE}" "${POD}" -c envoy --tail=200
kubectl logs -n "${NAMESPACE}" "${POD}" -c opa --tail=200

5. Жизненный цикл #

Путь обработки одного внешнего HTTP-запроса типов следующий:

Раздел не содержит reconcile, финализаторов и очередей controller-runtime для самого процесса API.

6. Параметры сервиса #

Конфигурация задаётся переменными окружения процесса. Важные для связки платформы переменные:

Где настраивать #

Сервисы и репозитории → Установленные сервисы → shturval-backend → Управлять. Сервис размещается в кластере управления.