Руководство администратора¶

Полное наименование: Компонент среды разработки сценариев видеоаналитики

Обозначение: LPI-VAP-RS

Краткое наименование: «Сценарии»

Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»)

Стандарт: ГОСТ 19.503-79

Аннотация¶

Настоящий документ является руководством администратора компонента среды разработки сценариев видеоаналитики (LPI-VAP-RS) — расширения программного продукта «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»; далее — Платформа 4.0). Документ предназначен для специалистов, выполняющих развёртывание, настройку, проверку и обслуживание серверных составных частей компонента.

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

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

Администратор должен владеть навыками администрирования Linux и Kubernetes, уметь работать с Helm и kubectl, понимать назначение PostgreSQL, S3-совместимого объектного хранилища, Kafka, Redis, очередей задач Celery, графических ускорителей и централизованного журналирования. Знание разработки сценариев видеоаналитики и моделей машинного обучения для выполнения штатных административных операций не требуется.

1. Общие сведения о программе¶

1.1. Назначение и функции программы¶

LPI-VAP-RS обеспечивает управляемый жизненный цикл сценариев видеоаналитики: от создания сценария и рабочей версии до настройки логики в визуальном редакторе, отладки на проверочных данных, публикации, применения на камерах и вывода из эксплуатации. Компонент также предоставляет каталог логических блоков, из которых собирается сценарий, и контур отладочного исполнения версии на изображениях и видеозаписях.

Таблица 1.1.1 — Группы задач администратора LPI-VAP-RS.

LPI-VAP-RS не выполняет непосредственную аутентификацию через СУДИР, подключение камер, исполнение опубликованных сценариев на рабочих видеопотоках и регистрацию событий. Единую точку входа, пользовательский контекст и назначение версий камерам предоставляет LPI-VAP-CORE; каталог моделей и их версий ведёт LPI-VAP-MM; исполнение опубликованных версий выполняет исполняющее ядро видеоаналитики Платформы 4.0.

1.2. Сведения о технических средствах¶

Компонент размещается на мастер-ноде и вычислительной ноде общего кластера Kubernetes Платформы 4.0. Отдельные физические серверы для LPI-VAP-RS не требуются, однако компоненту должны быть гарантированно выделены ресурсы, установленные проектом поставки.

Таблица 1.2.1 — Типы технических средств.

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

1.3. Сведения о программных средствах¶

Таблица 1.3.1 — Уровни программных средств.

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

2. Структура программы¶

2.1. Составные части программы¶

Таблица 2.1.1 — Составные части LPI-VAP-RS.

Обозначения sbx-*, wf-* и inf-* являются логическими именами составных частей, согласованными с описанием программы и текущими схемами развёртывания. Хранилища wf-scenario-storage, wf-asset-storage и wf-launch-storage поставляются дочерним чартом workflow родительского чарта box5; контур песочницы sbx-* и менеджер графов поставляются отдельными доменными чартами, имена ресурсов которых фиксируются в приложении В. При выполнении команд администратор использует имена из отрендеренного манифеста принятой версии поставки.

Веб-интерфейс, API-шлюз, средства единого входа, PostgreSQL, MinIO и Kafka Платформы 4.0 являются общеплатформенными или инфраструктурными средствами. Они нужны для работы LPI-VAP-RS, но не включаются в состав его прикладных сервисов. Хранилища проверочных данных и запусков, а также конвертеры администрируются совместно с LPI-VAP-MM; их резервное копирование и очистка описаны в руководстве администратора LPI-VAP-MM и в настоящем документе не дублируются.

2.2. Связи между составными частями¶

Схема 2.1 — Основные связи LPI-VAP-RS.

Для целевой поставки по каждой связи в приложении В фиксируются имя Kubernetes Service, пространство имён, протокол, направление соединения, способ проверки готовности, владелец реквизитов и признаки нарушения связи.

2.3. Связи с другими программами¶

Таблица 2.3.1 — Внешние связи компонента.

3. Настройка программы¶

3.1. Настройка на состав технических средств¶

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

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

1. Проверяет доступ к API Kubernetes и состояние всех предусмотренных проектом узлов. Узлы должны иметь состояние Ready, а системные поды DNS и сетевого плагина — быть готовы.
2. Сверяет проектные метки, affinity и tolerations. Сервисы wf-scenario-storage, sbx-sandbox-backend, sbx-node-red-vl, sbx-nginx и sbx-redis размещаются на узлах прикладного контура; sbx-celery и конвертеры — на вычислительных узлах с ресурсом nvidia.com/gpu.
3. Проверяет доступность StorageClass и постоянных томов. Метаданные хранятся в PostgreSQL, проверочные файлы и результаты — в S3-совместимом объектном хранилище, данные и конфигурации редактора, рабочие каталоги сессий и локальный кэш моделей — на постоянных томах контура песочницы. Удаление Helm-релиза не должно приводить к удалению этих данных.
4. Проверяет сетевую доступность PostgreSQL, MinIO, Kafka, реестра моделей LPI-VAP-MM, хранилища камер LPI-VAP-CORE и хранилищ проверочных данных и запусков из пространства имён поставки.
5. Проверяет синхронизацию времени на всех узлах. Расхождение времени нарушает сопоставление состояний сессий, отладочных задач, журналов и сообщений Kafka.
6. Создаёт imagePullSecret для доверенного реестра образов и убеждается, что сервисные учётные записи могут получить образы, указанные в формуляре.
7. Задаёт requests и limits по результатам нагрузочного расчёта: на каждую одновременную сессию редактора резервируется не менее 1 ГБ оперативной памяти, на каждый параллельный отладочный запуск — отдельный ускоритель и объём памяти не менее размера распакованных артефактов используемых моделей. Значения из демонстрационного values.yaml не используются как эксплуатационные без проверки на целевой нагрузке.
8. Проверяет запас ёмкости PostgreSQL, S3 и томов контура песочницы. Перед первичной загрузкой проверочных данных рекомендуется иметь не менее 20 % свободного пространства сверх расчётного объёма поставки.

Минимальная исходная проверка выполняется командами:

kubectl cluster-info
kubectl get nodes -o wide
kubectl get nodes --show-labels
kubectl get storageclass
kubectl get pods -A
helm version

Для вычислительной ноды дополнительно проверяется наличие ресурса GPU:

kubectl describe node <имя-вычислительной-ноды>

В секциях Capacity и Allocatable должен присутствовать ресурс nvidia.com/gpu в количестве, предусмотренном проектом. Проверка nvidia-smi в операционной системе не заменяет проверку предоставления GPU в Kubernetes.

Схема 3.1 — Размещение основных рабочих нагрузок LPI-VAP-RS.

3.1.1. Контроль готовности инфраструктуры¶

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

Таблица 3.1.1 — Контроль готовности инфраструктуры LPI-VAP-RS.

Результаты заносятся в протокол приложения Д. В протокол не включаются пароли, токены, закрытые ключи и полное содержимое Kubernetes Secret.

3.2. Развёртывание и запуск¶

LPI-VAP-RS развёртывается не отдельным compose-проектом, а в составе Helm-релиза родительского чарта box5. В командах используются следующие обозначения:

• <релиз> — имя Helm-релиза Платформы 4.0;
• <пространство> — пространство имён Kubernetes;
• <чарт> — каталог или пакет родительского чарта box5;
• <значения> — проверенный файл открытых параметров целевой поставки;
• <секреты> — защищённый YAML-файл значений для формирования Kubernetes Secret; файл не включается в дистрибутив с открытыми параметрами и не прикладывается к протоколу.

Таблица 3.2.1 — Основные команды развёртывания и контроля.

Команды с --set-file не выполняются с включённой трассировкой оболочки. Вывод helm template, kubectl get secret -o yaml и kubectl describe secret не добавляется в заявку сопровождения или общедоступный журнал.

3.2.1. Состав и проверка дистрибутива¶

Комплект установки должен включать родительский чарт box5, зафиксированные дочерние чарты, ведомость образов с digest, файл открытых значений, перечень требуемых секретов без их значений, данные редактора (каталог логических блоков, файлы допустимых моделей и категорий, конфигурации блоков), миграционные требования и эксплуатационные документы той же версии.

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

Таблица 3.2.2 — Соответствие логических и Kubernetes-имён.

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

1. Версии Chart.yaml и Chart.lock совпадают с формуляром, а digest файла блокировки не изменён после приёмки комплекта.
2. В values.yaml заданы согласованные адреса PostgreSQL, MinIO, Kafka и Redis, внутренние URL хранилища сценариев, менеджера графов, хранилищ проверочных данных и запусков, реестра моделей и хранилища камер, имена бакетов, топиков и групп.
3. Секретные параметры PostgreSQL, MinIO, Kafka, реестра образов и служебной учётной записи для синхронизации зон исключены из открытых ConfigMap и передаются через Kubernetes Secret или подключённое средство управления секретами.
4. Теги образов заменены неизменяемыми digest либо сопоставлены с digest в ведомости поставки. Образ исполнителя отладочных запусков соответствует варианту CUDA вычислительных узлов; версии исполнителя, редактора и исполняющего ядра видеоаналитики согласованы между собой.
5. Ресурсы, размещение, Service и сетевые политики соответствуют схеме кластера. Прямой внешний доступ к сервисам wf-* и sbx-* не открывается: пользовательские обращения проходят через общий API-шлюз по маршрутам /sandbox/ и /api/.
6. Средство наблюдения за очередью sbx-flower либо отключено, либо защищено учётными данными поставки; значение по умолчанию из демонстрационной конфигурации не используется.
7. Значения очистки архива и объектных данных оставлены штатными до утверждения сроков хранения и успешной проверки резервного копирования.

В типовом чарте probes для wf-scenario-storage параметризованы, но по умолчанию отключены. Их нельзя включать формально только ради состояния Ready: сначала на образах версии поставки проверяются фактические маршруты и семантика /healthz и /ready. Прикладной API среды предоставляет проверку GET /api/v1/health.

3.2.2. Первичное развёртывание¶

1. Создайте либо выберите пространство имён и проверьте квоты:

kubectl get namespace <пространство>
kubectl get resourcequota,limitrange -n <пространство>

1. Подготовьте imagePullSecret, открытый файл значений и защищённый файл секретов. Убедитесь, что последний доступен только исполнителю установки.
2. Подготовьте постоянные тома контура песочницы и заполните данные редактора из комплекта поставки: каталог конфигураций логических блоков, файл допустимых моделей и версий, файл допустимых категорий и перечень отключённых модулей (п. 3.3).
3. Выполните helm dependency build, helm lint и helm template командами таблицы 3.2.1. Проверьте отсутствие паролей и ключей в создаваемых ConfigMap, корректность имён Service и отсутствие незапланированного внешнего NodePort.
4. Установите релиз командой helm upgrade --install из таблицы 3.2.1.
5. Проверьте состояние релиза, Deployment и событий пространства имён. Должны появиться wf-scenario-storage, sbx-sandbox-backend, sbx-node-red-vl, sbx-celery, sbx-redis, sbx-nginx, конвертеры и inf-flows-manager.
6. Убедитесь, что init-контейнеры подготовки базы данных завершились с кодом 0, миграции хранилища сценариев применены, а основные контейнеры не находятся в CrashLoopBackOff или ImagePullBackOff.
7. Выполните контроль по подразделу 3.2.5 и сквозные примеры раздела 4.

Если --atomic вернул ошибку и удалил неуспешную редакцию, сначала сохраните события и журналы доступных подов, устраните причину, затем повторите установку. Не отключайте ожидание готовности, чтобы скрыть ошибку инициализации.

3.2.3. Порядок запуска составных частей¶

Kubernetes может запускать независимые Deployment параллельно, поэтому порядок обеспечивается init-контейнерами, проверками готовности и повторными подключениями, а контролируется по следующим группам:

1. PostgreSQL, MinIO, Kafka Платформы 4.0 и Redis контура песочницы доступны по сетевым именам, указанным в конфигурации.
2. Init-контейнер создаёт или проверяет базу хранилища сценариев; при старте wf-scenario-storage ожидает объявленные зависимости, применяет миграции схемы и запускает прикладной сервер. Хранилища проверочных данных и запусков запускаются в том же порядке.
3. Запускаются sbx-node-red-vl вместе с менеджером сессий и inf-flows-manager; редактор загружает каталог логических блоков и конфигурации блоков с постоянного тома.
4. Запускается sbx-sandbox-backend: ожидает MinIO, Kafka и Redis, регистрирует потребителей сообщений о версиях моделей и состояниях запусков.
5. Запускаются sbx-celery и конвертеры: исполнитель синхронизирует зоны и модели из Платформы 4.0, подключается к очереди и получает GPU.
6. Настраиваются маршруты sbx-nginx и общего API-шлюза: /sandbox/ — к контуру песочницы, /api/ — к хранилищам и прикладному API.
7. Проверяются потребители Kafka и прохождение состояний сессии и запуска через канал оперативных уведомлений интерфейса.

Отсутствие готового исполнителя и конвертеров не препятствует открытию каталога сценариев и редактированию графа, но делает невозможной отладку и проверочный запуск. Поэтому доступность страницы «Сценарии» не является достаточным признаком успешного запуска LPI-VAP-RS.

3.2.4. Остановка и перезапуск¶

Перед плановой остановкой прекратите приём новых сессий редактора и отладочных запусков, затем дождитесь завершения активных операций либо остановите их штатной функцией компонента. Пользователи должны сохранить графы: сессии редактора закрываются при остановке, незафиксированные изменения графа утрачиваются. Принудительное завершение во время записи в S3 может оставить объекты, не связанные с завершённой записью метаданных.

Перезапуск прикладных сервисов выполняется средствами Kubernetes:

kubectl rollout restart deployment/wf-scenario-storage -n <пространство>
kubectl rollout restart deployment/sbx-sandbox-backend -n <пространство>
kubectl rollout restart deployment/sbx-node-red-vl -n <пространство>
kubectl rollout restart deployment/sbx-celery -n <пространство>
kubectl rollout status deployment/wf-scenario-storage -n <пространство>
kubectl rollout status deployment/sbx-sandbox-backend -n <пространство>
kubectl rollout status deployment/sbx-node-red-vl -n <пространство>
kubectl rollout status deployment/sbx-celery -n <пространство>

Перезапуск sbx-node-red-vl завершает все экземпляры редактора и открытые сессии; перезапуск sbx-celery прерывает выполняемые отладочные задачи. Если изменена Helm-конфигурация, выполняйте helm upgrade, а не ручное редактирование Deployment. Запуск процесса внутри контейнера и удаление Helm-релиза не являются штатными способами перезапуска. Перед остановкой PostgreSQL, MinIO, Kafka или Redis останавливаются зависящие от них прикладные и вычислительные нагрузки.

3.2.5. Признаки успешного запуска¶

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

• helm status показывает установленную редакцию без неуспешных hook и Job;
• Deployment wf-scenario-storage, sbx-sandbox-backend, sbx-node-red-vl, sbx-celery и inf-flows-manager имеют требуемое число доступных реплик;
• init-контейнер базы данных завершён, миграции хранилища сценариев применены, число перезапусков основных контейнеров не растёт;
• внутренние Service имеют EndpointSlice с адресами готовых подов;
• из подов открывается /api/docs/ хранилища сценариев на порту 3000 и /api/v1/health прикладного API среды; эта проверка подтверждает доступность HTTP-процессов, но не заменяет функциональный пример;
• менеджер сессий редактора отвечает на служебный запрос и создаёт экземпляр редактора для тестовой сессии;
• сервисы подключились к PostgreSQL, MinIO, Kafka и Redis без повторяющихся ошибок авторизации, TLS или разрешения имён;
• исполнитель отладочных запусков зарегистрирован в очереди и получил GPU;
• в интерфейсе через общий шлюз открывается раздел «Сценарии», для рабочей версии открывается песочница с загруженной палитрой блоков;
• эталонная версия сценария проходит отладку на эталонном файле с получением визуализированных кадров, журналов и событий, публикуется и появляется в перечне опубликованных версий у исполняющего ядра видеоаналитики.

Основные команды контроля:

helm status <релиз> -n <пространство>
kubectl get deployment,pod,service,endpointslice -n <пространство>
kubectl get events -n <пространство> --sort-by=.lastTimestamp
kubectl logs deployment/wf-scenario-storage -n <пространство> --tail=200
kubectl logs deployment/sbx-sandbox-backend -n <пространство> --tail=200
kubectl logs deployment/sbx-node-red-vl -n <пространство> --tail=200
kubectl logs deployment/sbx-celery -n <пространство> --tail=200

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

3.3. Выбор функций¶

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

Таблица 3.3.1 — Выбор функций LPI-VAP-RS.

Состав палитры и перечень доступных моделей задаются данными редактора на постоянном томе: файлом отключённых модулей Node-RED, файлом допустимых моделей и версий (selected-models.csv) и файлом допустимых категорий (selected-categories.yaml). Эти файлы поставляются в составе дистрибутива и изменяются администратором только по согласованному перечню; после изменения перезапускается редактор и выполняется «Обновить зоны и модели из СОВА» в тестовой сессии. Одинаковый состав блоков должен быть у исполнителя отладочных запусков и у исполняющего ядра видеоаналитики: сценарий, отлаженный с блоком, отсутствующим в промышленном контуре, не может быть исполнен на камерах.

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

3.4. Настройка режимов работы¶

3.4.1. Сессии редактора¶

Фиксируются число одновременных сессий, ресурсы одного экземпляра редактора, срок неактивной сессии и порядок её закрытия. Каждая сессия запускает отдельный процесс редактора и рабочий каталог на томе сессий; экземпляры создаются и останавливаются менеджером сессий по запросам прикладного API. Проверка включает открытие нескольких сессий разными пользователями, корректное закрытие сессии кнопкой «Вернуться к сценарию» и освобождение ресурсов после ухода со страницы.

3.4.2. Отладочные запуски и очередь задач¶

Фиксируются число исполнителей и параллелизм очереди (параметр MAX_WORKERS_COUNT), выделение GPU (CUDA_VISIBLE_DEVICES, IS_USE_GPU), тайм-аут постановки задачи (CELERY_TIMEOUT_TASK), параметры повторного подключения к Redis и поток состояний обработки. Исполнитель обрабатывает одну задачу на процесс и перезапускает процесс после каждой задачи; параллелизм повышается только после контроля памяти GPU, времени очереди и влияния на рабочую видеоаналитику Центрального модуля. Повтор отказавшей задачи не создаётся, пока не установлено, завершилась ли исходная.

3.4.3. Проверочные файлы и зоны¶

Фиксируются предельные размер, разрешение и длительность файлов, принимаемых прикладным API и общим шлюзом (client_max_body_size на маршрутах /sandbox/ и /api/), режим работы с зонами исполнителя (ZONE_STORAGE_WORK_MODE, ZONES_METHOD) и параметры прямой передачи объектов в S3 (MINIO_PREFIX, сроки действия подписанных ссылок). Лимиты задаются согласованно на шлюзе, маршрутизаторе контура песочницы и прикладном API: увеличение только одного из них не обеспечивает приём большего файла.

3.4.4. Модели отладочного контура¶

Фиксируются порядок источников моделей (MODEL_REGISTRIES_PRIORITY: сначала локальный кэш, затем реестр моделей LPI-VAP-MM по адресу VLFLOW_ENDPOINT), каталог кэша моделей (MODELS_PATH), адреса Unix-сокетов конвертеров (YOLO_CONVERSION_URI, MMLAB_CONVERSION_URI) и регламент очистки кэша. Исполнитель получает опубликованные версии моделей из реестра и сохраняет подготовленные представления в кэше; доступ к внешним источникам моделей (MLflow, репозитории разработки) в целевом контуре не настраивается.

3.4.5. Публикация и интеграционный обмен¶

Фиксируются топики Kafka хранилища сценариев: публикуемые current_scenarios, scenarios_settings_updated, scenario_deleted, scenario_restored и потребляемые create_zone_type, update_zone_type, remove_zone_type; группы потребителей; топики прикладного API среды о версиях моделей (model_version_ready, model_version_updated, model_version_deleted) и о состояниях запусков (change_launch_status, continue_launch); адреса хранилища камер и менеджера графов. Публикация считается завершённой не по факту отправки команды, а после появления версии в перечне опубликованных версий у исполняющего ядра. Служебная учётная запись, под которой исполнитель синхронизирует зоны и модели из Платформы 4.0 (BOX_URL, BOX_LOGIN, BOX_PASSWORD), выдаётся с минимальными правами и хранится в Secret.

3.4.6. Хранение и очистка¶

Фиксируются период очистки архива хранилища сценариев (ARCHIVE_CLEANUP_INTERVAL_SEC, по умолчанию одни сутки), сроки хранения архивных сценариев и версий, задаваемые в интерфейсе, сроки хранения рабочих каталогов сессий и результатов отладки на томе контура песочницы, а также параметры очистки бакетов проверочных данных и запусков, общие с LPI-VAP-MM.

3.4.7. Журналирование и мониторинг¶

Фиксируются уровни журналирования (LOGGER_LEVEL, LOGGING_LEVEL), метрики готовности, числа сессий, длины очереди, длительности и ошибок отладочных задач, заполнения хранилищ и томов, пороги оповещения и доступ к средству наблюдения за очередью. В журналы включаются идентификаторы сценария, версии, сессии, запуска и задачи, достаточные для сквозной корреляции, но не содержимое Secret и подписанные S3-адреса. Повышенный уровень включается на ограниченный интервал.

3.5. Настройка доступа¶

Настройка подключения Платформы 4.0 к СУДИР относится к LPI-VAP-CORE. Для LPI-VAP-RS администратор проверяет получение доверенного пользовательского контекста через общий шлюз и соответствие полномочий операциям просмотра, создания, редактирования, отладки, публикации, архивирования и удаления. Прямое подключение RS к СУДИР и отдельный OIDC-клиент не настраиваются.

Маршруты контура песочницы /sandbox/ публикуются только через общий шлюз; экземпляры редактора адресуются по идентификатору сессии и не должны быть доступны в обход шлюза. Средство наблюдения за очередью по маршруту /sandbox/flower/ доступно только администратору из служебной сети.

Таблица 3.5.1 — Контроль настройки доступа LPI-VAP-RS.

3.6. Защита конфигурации, секретов и сертификатов¶

Открытые параметры размещаются в конфигурации Helm и ConfigMap, секретные — в Kubernetes Secret либо подключённом средстве управления секретами. К секретным относятся реквизиты PostgreSQL, MinIO, Kafka, Redis, реестра образов, служебной учётной записи синхронизации зон и моделей и учётные данные средства наблюдения за очередью. В целевой поставке определяются владельцы значений, минимальные права сервисных учётных записей, период ротации и пороги срока действия сертификатов.

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

1. определить всех потребителей изменяемого реквизита и возможность периода совместного действия старого и нового значения;
2. создать новую версию Secret средствами принятого защищённого хранилища;
3. применить изменение сначала к зависимой стороне, допускающей два значения, затем последовательно перезапустить потребителей в окно, когда нет активных сессий редактора и отладочных задач;
4. выполнить проверки соединения и контрольный пример раздела 4;
5. отозвать прежнее значение после подтверждения работы всех потребителей;
6. проверить журналы и диагностические пакеты на отсутствие раскрытого значения.

Экспорт Secret, полный вывод переменных окружения и сохранение отрендерированного Secret в открытом протоколе запрещены. Сертификаты MinIO, Kafka, Ingress и реестра образов проверяются до истечения срока, чтобы их замена не совпала с обновлением прикладных образов. Пользовательские Python-блоки, подключаемые в каталог блоков, проходят согласование и проверку до включения в дистрибутив: они исполняются с правами исполнителя отладочных запусков и исполняющего ядра.

4. Проверка программы¶

4.1. Способы проверки работоспособности¶

Проверка строится по уровням: состояние Kubernetes; доступность хранилищ и очередей; готовность прикладных API и менеджера сессий; прохождение отладочной задачи; сквозной пользовательский сценарий. Состояние Running само по себе не подтверждает работоспособность компонента.

Таблица 4.1.1 — Уровни проверки работоспособности LPI-VAP-RS.

4.2. Контрольные примеры¶

Таблица 4.2.1 — Набор контрольных примеров.

4.3. Результаты проверки¶

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

Результат проверки оформляется по приложению Д. К протоколу прилагаются ведомость образов и digest, состав данных редактора (перечень блоков, файлы допустимых моделей и категорий), идентификаторы эталонных объектов и задач, а также ссылки на очищенные от секретов журналы. Неприменимая проверка не пропускается без записи: указываются причина, решение ответственного лица и влияние на приёмку. После исправления ошибки повторяется отказавший пример и связанные с ним проверки, а не только отдельный запрос, на котором проявился отказ.

5. Дополнительные возможности¶

5.1. Резервное копирование и восстановление¶

5.1.1. Состав резервируемых данных¶

Резервная копия LPI-VAP-RS должна позволять восстановить каталог сценариев, графы версий, данные редактора и результаты проверок в согласованное состояние. Имена баз, томов и бакетов из таблицы 5.1.1 являются типовыми; перед настройкой задания они сверяются с отрендерированным Helm-манифестом целевой поставки.

Таблица 5.1.1 — Состав резервной копии LPI-VAP-RS.

Kafka и Redis обеспечивают доставку сообщений, состояние сессий и выполнение асинхронных задач, но не заменяют основные хранилища данных. Необходимость резервирования их состояния определяется общеплатформенным регламентом. Если ожидающие сообщения и задачи не резервируются, перед копированием прекращают создание новых сессий и запусков, дожидаются завершения активных либо фиксируют их идентификаторы для последующей сверки.

Не требуется включать в резервную копию контейнерные образы, локальный кэш моделей, временные каталоги конвертеров и Unix-сокеты, если они воспроизводятся из доверенного реестра и сохранённых объектов. Наличие образов требуемых digest в реестре проверяется отдельно.

5.1.2. Подготовка и выполнение копирования¶

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

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

1. Проверяет успешность предыдущего задания, доступность целевого хранилища и запас места.
2. Фиксирует время начала, имя и редакцию Helm-релиза, версии образов, число открытых сессий редактора и активных отладочных задач.
3. Прекращает приём новых сессий и запусков на время, необходимое для формирования согласованной точки, либо применяет поддерживаемый механизм snapshot без остановки записи.
4. Формирует копию базы хранилища сценариев, тома данных редактора и, по регламенту, тома сессий. Выбранный способ должен исключать появление в восстановленном каталоге версий без графа.
5. Сохраняет конфигурацию Helm и защищённую копию секретов, соответствующие той же редакции приложения.
6. Проверяет завершение заданий, объём, контрольные суммы и возможность чтения каталога копии; затем возобновляет операции компонента.
7. Регистрирует результат, срок хранения, ответственного и выявленные отклонения в эксплуатационном журнале.

Копирование только PVC без предусмотренного приложением механизма quiesce или snapshot не считается согласованной резервной копией. Копия базы сценариев без тома данных редактора не обеспечивает восстановление палитры блоков той же версии, а без бакетов проверочных данных и запусков — восстановление результатов проверок.

5.1.3. Восстановление¶

Восстановление сначала проверяется на изолированном контуре. Подключать его к рабочим топикам Kafka и внешнему API-шлюзу запрещается, чтобы тест не изменил рабочие состояния и не опубликовал сценарии повторно исполняющему ядру.

1. Выберите одну согласованную точку восстановления и проверьте наличие всех частей копии и поддерживаемой версии образов.
2. Ограничьте входной трафик к LPI-VAP-RS. Зафиксируйте исходное число реплик, затем остановите прикладные сервисы, редактор и исполнителей, способных записывать в восстанавливаемые хранилища.
3. Восстановите базу хранилища сценариев, том данных редактора и, при необходимости, том сессий из той же согласованной точки. Хранилища проверочных данных и запусков восстанавливаются по регламенту LPI-VAP-MM из той же точки.
4. Восстановите конфигурацию и секреты, примените соответствующий Helm-релиз и дождитесь завершения миграций и готовности рабочих нагрузок.
5. Сверьте незавершённые на момент копии сессии и запуски. Зависшие операции не переводятся в успешное состояние вручную; их останавливают или повторяют штатной операцией после анализа журналов.
6. Выполните проверки таблицы 5.1.2 и контрольные примеры раздела 4. Входной трафик возвращается только после положительного результата.

Таблица 5.1.2 — Проверки после восстановления.

Контрольное восстановление проводится периодически с частотой, установленной регламентом, и после изменения способа копирования. Успешное завершение задания копирования без контрольного восстановления не подтверждает пригодность копии.

5.1.4. Автоматизация и ротация копий¶

Автоматическое копирование выполняется Kubernetes CronJob, оператором СУБД или внешней системой резервного копирования. Реализация должна обеспечивать:

• запрет параллельного запуска двух копирований одного набора данных;
• ограничение длительности и контролируемый повтор после временного отказа;
• шифрование копий при передаче и хранении;
• оповещение об ошибке, отсутствии свежей копии и недостатке места;
• ротацию по утверждённому сроку без удаления последней успешной копии;
• журналирование без паролей, ключей, токенов и подписанных S3-адресов.

Перед включением автоматической ротации маска удаления проверяется на тестовом наборе. Она должна быть ограничена каталогом или бакетом резервных копий и не может совпадать с путями томов редактора и сессий или префиксами рабочих данных LPI-VAP-RS.

5.2. Обновление версий и откат¶

До изменения релиза оформляется план обновления.

Таблица 5.2.1 — План обновления LPI-VAP-RS.

Порядок обновления:

1. Сопоставьте формуляр исходной и целевой поставок. Проверьте изменение схем, параметров, состава блоков и контрактов с LPI-VAP-CORE, LPI-VAP-MM и исполняющим ядром. Обновление каталога блоков согласуется с обновлением исполняющего ядра: опубликованные сценарии должны исполняться обеими версиями.
2. Проверьте helm history, состояние подов, PVC, хранилищ и очередей. До начала работ устраните исходные ошибки и нехватку ресурсов.
3. Уведомите пользователей, дождитесь сохранения графов и закрытия сессий редактора, завершения отладочных задач и запусков либо остановите их штатным способом. Выполните резервное копирование по 5.1.
4. Подготовьте новый чарт, значения и данные редактора. Выполните helm lint и helm template, сравните Deployment, Service, Secret, задания и параметры миграций с текущей редакцией. Отрендерированный Secret не сохраняйте в открытом протоколе.
5. Выполните helm upgrade с ключами --atomic --wait и установленным для поставки тайм-аутом. Не запускайте миграции базы вручную параллельно с init-контейнерами чарта.
6. Проверьте helm status, состояние миграций, доступность хранилища сценариев, прикладного API, редактора и исполнителя, отставание групп Kafka и журналы конвертеров.
7. Откройте в режиме просмотра несколько опубликованных версий, в том числе с пользовательскими блоками, и убедитесь, что графы загружаются без предупреждений о неизвестных блоках.
8. Выполните контрольные примеры раздела 4 и зарегистрируйте принятую редакцию.

Способ отката зависит от изменения данных:

Схема 5.1 — Выбор способа отката обновления.

helm rollback возвращает Kubernetes-ресурсы предыдущей редакции, но не отменяет уже выполненные необратимые изменения PostgreSQL, формата графов и данных редактора. В таком случае восстанавливается весь согласованный набор данных по 5.1. Предыдущие чарты, образы и данные редактора не удаляются до подтверждения новой версии и окончания установленного периода наблюдения.

5.3. Управление ёмкостью и очистка данных¶

Таблица 5.3.1 — Объекты контроля ёмкости LPI-VAP-RS.

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

1. Утвердить сроки хранения архивных сценариев и версий.
2. Проверить резервную копию и возможность восстановления.
3. Убедиться, что архивные версии не требуются для воспроизведения событий, зарегистрированных по ним, в течение установленного срока хранения событий.
4. Изменить срок штатной операцией интерфейса и проконтролировать первый цикл очистки по журналам и архиву.

При достижении порога заполнения сначала определяется источник роста и проверяется работа штатной очистки. Затем, в зависимости от причины, увеличивается том или квота S3, корректируется срок хранения либо временно ограничиваются новые сессии и запуски. Расширение PVC выполняется только для StorageClass, допускающего увеличение; существующий PVC не уменьшается.

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

5.4. Диагностические средства и журналы¶

Таблица 5.4.1 — Диагностические средства LPI-VAP-RS.

Рекомендуемый порядок диагностики:

1. Зафиксировать время, операцию, идентификаторы сущностей и отображаемое состояние. Не повторять массово операцию до определения, была ли она фактически принята.
2. Определить границу отказа: хранилище сценариев и PostgreSQL, прикладной API среды, менеджер сессий и редактор, очередь и исполнитель, конвертер, S3, брокер либо смежный компонент.
3. Проверить Helm-релиз, готовность подов, число перезапусков, init-контейнеры, EndpointSlice, PVC и события пространства имён.
4. Найти записи за интервал инцидента по идентификатору сценария, версии, сессии или запуска и сопоставить время между связанными сервисами.
5. Проверить доступность PostgreSQL, MinIO, Kafka и Redis и наличие ресурса GPU, не выводя реквизиты подключения.
6. После устранения причины повторить затронутый контрольный пример раздела 4 и проверить связанные функции.

Минимальный безопасный набор команд:

helm status <релиз> -n <пространство>
helm history <релиз> -n <пространство>
kubectl get deploy,pod,svc,endpointslice,pvc -n <пространство> -o wide
kubectl get events -n <пространство> --sort-by=.lastTimestamp
kubectl logs <под> -n <пространство> -c <контейнер> --since=30m
kubectl logs <под> -n <пространство> -c <контейнер> --previous --tail=200

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

Диагностический пакет содержит описание и время инцидента, версии релиза и образов, отфильтрованные состояния ресурсов, события, относящиеся к отказу журналы, идентификаторы затронутых сущностей и, при согласовании, граф версии. Из него удаляются значения Secret, строки подключения, токены, подписанные S3-адреса и пользовательские медиафайлы, не требуемые для разбора. Полные выгрузки kubectl cluster-info dump, переменных окружения и ресурсов Secret не прикладываются.

5.5. Масштабирование¶

Масштабируются три разные группы нагрузок:

• хранилище сценариев wf-scenario-storage — по числу запросов, длительности ответа и соединениям с PostgreSQL;
• редактор и прикладной API среды — по числу одновременных сессий: каждая сессия занимает отдельный процесс редактора, оперативную память и рабочий каталог;
• исполнитель отладочных запусков и конвертеры — по длине очереди, времени ожидания, числу задач и доступным GPU.

Простое увеличение реплик хранилища не ускоряет отладку. Добавление исполнителей не устраняет ограничение оперативной памяти мастер-ноды под сессии редактора и пропускной способности PostgreSQL, MinIO, Kafka или сети.

Перед горизонтальным масштабированием администратор проверяет:

1. допускает ли сервис несколько реплик: менеджер сессий и прикладной API хранят состояние сессий в Redis и на разделяемом томе, поэтому реплики должны иметь доступ к одному тому и одному Redis;
2. не выполняет ли каждая реплика хранилища сценариев одну и ту же периодическую очистку архива;
3. имеются ли свободные GPU, видеопамять, CPU, RAM и ephemeral storage;
4. соответствуют ли nodeSelector, affinity, tolerations и запрос nvidia.com/gpu целевым вычислительным узлам;
5. выдерживают ли PostgreSQL, MinIO, Kafka и Redis возросшее число подключений и поток данных;
6. не вытеснит ли отладочная нагрузка рабочую видеоаналитику LPI-VAP-CORE.

Изменение выполняется через файл значений Helm с последующим helm upgrade. Ручное масштабирование kubectl scale допустимо только как временная мера при инциденте: желаемое число реплик затем переносится в Helm-конфигурацию, иначе следующее обновление его отменит.

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

При выводе вычислительной ноды новые задачи на неё не направляются; активным задачам дают завершиться либо штатно останавливают их. Затем ноду переводят в состояние cordon, выполняют drain с учётом локального кэша моделей и PodDisruptionBudget и проверяют повторное размещение исполнителя. Перед удалением ноды подтверждается достаточность ресурсов оставшегося контура.

6. Сообщения системному программисту¶

Сообщения LPI-VAP-RS выводятся в веб-интерфейсе, ответах прикладных интерфейсов, событиях Kubernetes и журналах составных частей. В таблицах ниже приведены устойчивые признаки сообщений, их смысл и безопасный порядок действий. Точная формулировка может различаться между версиями образов, поэтому при диагностике вместе с сообщением фиксируются время, имя составной части, версия образа и идентификаторы сценария, версии, сессии, запуска или фоновой задачи. Пользовательские сообщения и действия с объектами приведены в руководстве пользователя.

6.1. Сообщения при настройке¶

Таблица 6.1.1 — Сообщения и признаки ошибок при настройке.

6.2. Сообщения при проверке¶

Таблица 6.2.1 — Сообщения и признаки ошибок при проверке программы.

6.3. Сообщения при выполнении программы¶

Таблица 6.3.1 — Сообщения и признаки отказов при выполнении программы.

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

6.4. Диагностические коды¶

Таблица 6.4.1 — Диагностические коды и признаки состояний LPI-VAP-RS.

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

Приложения¶

Приложение А (обязательное). Параметры настройки¶

Значения целевой поставки фиксируются в файле значений Helm, защищённом хранилище реквизитов и формуляре. Имена путей в values.yaml могут различаться между редакциями чарта; перед изменением используется схема и результат helm template принятой версии, а не имя из другой поставки.

Таблица А.1 — Параметры настройки LPI-VAP-RS.

Таблица А.2 — Карта применения параметров целевой поставки.

Приложение Б (рекомендуемое). Регламентные операции обслуживания¶

Таблица Б.1 — Регламентные операции обслуживания LPI-VAP-RS.

Приложение В (обязательное при подготовке целевой поставки). Уточняемые сведения¶

Таблица В.1 — Сведения, уточняемые для целевой поставки.

Приложение Г (справочное). Исходные тексты схем Mermaid¶

RS-AG-MER-001. Схема 2.1 — Основные связи LPI-VAP-RS¶

Расположение схемы: 2.2. Связи между составными частями.

flowchart TB
    CORE["LPI-VAP-CORE<br/>единый вход и пользовательский контекст"]
    UI["Веб-интерфейс и API-шлюз"]

    subgraph RS["LPI-VAP-RS"]
        NG["sbx-nginx"]
        SB["sbx-sandbox-backend"]
        NR["sbx-node-red-vl"]
        CEL["sbx-celery"]
        SCONV["Конвертеры<br/>отладочного контура"]
        SS["wf-scenario-storage"]
        FM["inf-flows-manager"]
    end

    AS["wf-asset-storage"]
    LS["wf-launch-storage"]
    DB[("PostgreSQL")]
    S3[("MinIO")]
    K["Kafka Платформы 4.0"]
    R["Redis контура песочницы"]
    MM["LPI-VAP-MM<br/>реестр моделей"]
    CAM["Хранилище камер<br/>LPI-VAP-CORE"]
    INF["Исполняющее ядро<br/>видеоаналитики"]

    CORE --> UI
    UI --> NG
    UI --> SS
    UI --> LS
    UI --> AS
    NG --> SB
    NG --> NR
    SB --> NR
    SB --> R
    SB --> CEL
    CEL --> R
    CEL --> SCONV
    CEL --> S3
    SB --> SS
    SB --> FM
    SB --> AS
    LS --> SB
    SS --> DB
    SS <--> K
    FM --> SS
    K <--> FM
    MM --> FM
    MM --> K
    SS --> CAM
    K --> INF

RS-AG-MER-002. Схема 3.1 — Размещение основных рабочих нагрузок LPI-VAP-RS¶

Расположение схемы: 3.1. Настройка на состав технических средств.

flowchart LR
    GW["Общий API-шлюз<br/>Платформы 4.0"]

    subgraph K8S["Кластер Kubernetes"]
        subgraph APP["Узлы прикладного контура"]
            NG["sbx-nginx"]
            SB["sbx-sandbox-backend"]
            NR["sbx-node-red-vl<br/>экземпляры редактора"]
            SS["wf-scenario-storage"]
            FM["inf-flows-manager"]
            VOL[("Тома: данные и конфигурации<br/>редактора, сессии")]
            NR --> VOL
            SB --> VOL
        end
        subgraph GPU["Вычислительные узлы"]
            CEL["sbx-celery"]
            CV["Конвертеры<br/>отладочного контура"]
            CACHE[("Кэш моделей")]
            DEV["nvidia.com/gpu"]
            CEL --> CV --> DEV
            CEL --> DEV
            CEL --> CACHE
        end
    end

    PG[("PostgreSQL")]
    S3[("MinIO / S3")]
    K[("Kafka")]
    R[("Redis контура песочницы")]

    GW --> NG
    GW --> SS
    NG --> SB
    NG --> NR
    SB --> NR
    SB --> SS
    SB --> FM
    SB <--> R
    CEL <--> R
    CEL --> S3
    SS --> PG
    SS <--> K
    K <--> FM

RS-AG-MER-003. Схема 5.1 — Выбор способа отката обновления¶

Расположение схемы: 5.2. Обновление версий и откат.

flowchart TD
    START["Применена новая редакция"] --> MIG{"Миграции и преобразования<br/>завершились успешно?"}
    MIG -- "Нет" --> RESTORE["Остановить сервисы;<br/>восстановить БД, тома редактора и конфигурацию<br/>из согласованной копии"]
    MIG -- "Да" --> CHECK{"Проверки раздела 4<br/>успешны?"}
    CHECK -- "Да" --> ACCEPT["Зафиксировать приёмку<br/>новой редакции"]
    CHECK -- "Нет" --> REV{"Новая схема данных и формат графа<br/>совместимы с прежней версией?"}
    REV -- "Да" --> HELM["Выполнить helm rollback<br/>и повторить проверки"]
    REV -- "Нет" --> RESTORE

Приложение Д (рекомендуемое). Протокол установки и приёмочной проверки¶

Таблица Д.1 — Форма протокола установки и приёмочной проверки.

Приложение Е (рекомендуемое). Состав диагностического пакета¶

Таблица Е.1 — Состав диагностического пакета LPI-VAP-RS.

Лист регистрации изменений¶

Таблица — Лист регистрации изменений.

Рабочая редакция 0.1 содержит заполненные сведения по всем разделам ГОСТ 19.503-79 и приложениям: назначение и границы ответственности, структуру и связи составных частей, подготовку инфраструктуры и развёртывание в Kubernetes, выбор функций и режимы работы, доступ и защиту конфигурации, проверку, резервное копирование, обновление, ёмкость, диагностику, масштабирование, сообщения и диагностические коды, параметры настройки, регламентные операции и состав диагностического пакета. Структура и оформление согласованы с руководством администратора компонента управления моделями; состав составных частей, параметры и маршруты сверены с исходным кодом сервисов, схемами развёртывания и действующей установкой BOX5. Редакция не является зарегистрированным изменением утверждённого оригинала. История подготовки рабочей редакции сохраняется в Git и не заменяет оформленный лист регистрации изменений.