Результаты апробации
ГЛАВА 4. ПРАКТИЧЕСКАЯ АПРОБАЦИЯ ИНФРАСТРУКТУРЫ И КЛИЕНТСКОЙ ЧАСТИ
В главе представлены методология и результаты апробации разработанной платформы по четырём направлениям: функциональное тестирование, нагрузочные испытания, проверка механизмов безопасности и оценка эксплуатационного эффекта автоматизации. Для каждого направления приведены измеримые результаты и их интерпретация.
4.1 Организация апробации
Апробация проведена на тестовом Kubernetes-кластере версии 1.29 из трёх узлов: один управляющий узел и два рабочих узла. Узлы развёрнуты как виртуальные машины на базе KVM-гипервизора. Суммарные ресурсы кластера: 24 vCPU и 48 GiB RAM. Сетевой профиль: 10 Gbit/s виртуальная сеть между узлами. Среда выполнения контейнеров: containerd 1.7. CNI-плагин: Calico (обеспечивает поддержку NetworkPolicy). Нагрузочное тестирование API проводилось инструментом k6 версии 0.50, сценарий предусматривал нарастающую нагрузку от 0 до 50 виртуальных пользователей за 60 секунд с удержанием в течение 300 секунд. Проверка изоляции выполнялась посредством попыток соединений типа "под-к-поду" между Pod'ами пространства имён labs с использованием kubectl exec и curl.
4.2 Функциональные результаты
Проверены все критичные пользовательские и системные сценарии, включая: аутентификацию и ролевую авторизацию через Keycloak OIDC; назначение и запуск лабораторных заданий преподавателем; создание изолированной среды на каждого пользователя; автоматическое завершение по TTL; очистку пространства имён и освобождение ресурсов. Во всех проверенных сценариях достигнута корректная последовательность переходов состояния FSM без ручного вмешательства оператора. Все семь функциональных требований (ФТ-1...ФТ-7) выполнены в полном объёме.
4.3 Нагрузочные результаты
Таблица 5 содержит результаты нагрузочного тестирования API при 50 одновременных клиентских соединениях, а также результаты нагрузочного тестирования запуска 30 параллельных лабораторных сессий.
Таблица 5. Результаты нагрузочного тестирования
| Параметр | 50 клиентов (стенд) | Целевой SLO | Резерв | Инструмент измерения |
|---|---|---|---|---|
| Медиана задержки (p50) | 47 мс | < 200 мс | 76% | k6 (нагрузочный тест) |
| 95-й перцентиль (p95) | 213 мс | < 500 мс | 57% | k6 (нагрузочный тест) |
| Доля ошибок API | 0% | < 1% | 100% | k6 + Prometheus |
| Утилизация CPU | ~68% | < 85% | 20% | Prometheus / cAdvisor |
| Утилизация RAM | ~71% | < 85% | 17% | Prometheus / cAdvisor |
При одновременном запуске 30 сессий зафиксированы следующие значения: среднее время запуска составило 18,3 с (без прогретого кэша образов), что соответствует НФТ-1 (≤ 20 с); максимальное время запуска достигло 34,7 с (одно аномальное значение при первичном скачивании образа); среднее время при прогретом кэше составило 6,1 с. Медианная задержка API составила 47 мс, p95 достигла 213 мс, доля ошибок равна 0%. Утилизация CPU в пике составила ~68%, RAM составила ~71%, что сохраняет резерв для пиковых колебаний нагрузки в пределах ~20%.
4.4 Результаты проверки безопасности
Проверка сетевой изоляции включала серию попыток соединений типа "под-к-поду" между Pod'ами пространства имён labs (N = 50 попыток). Все попытки были заблокированы NetworkPolicy; коэффициент изоляции составил 0/50 = 0% успешных межсессионных соединений, что полностью соответствует НФТ-3. Попытки обращения к сервисам пространств имён platform и infrastructure из учебных контейнеров также блокировались политиками сети.
Тесты на эскалацию привилегий (запуск процессов от имени суперпользователя, привилегированные операции, небезопасные системные вызовы через специально подготовленный тестовый под) показали корректное срабатывание SecurityContext и seccomp-политик: все попытки были отклонены OOMKiller или завершались EPERM. При запуске стресс-нагрузки (stress-ng) внутри учебных подов подтверждена корректная работа cgroup-ограничений: превышение лимитов CPU и RAM не приводило к деградации соседних сессий или инфраструктурных сервисов.
4.5 Верификация нефункциональных требований
Таблица 6 содержит сводную верификацию всех нефункциональных требований, сформулированных в разделе 1.5.
Таблица 6. Верификация нефункциональных требований
| ID | Требование | Целевое значение | Фактический результат | Статус |
|---|---|---|---|---|
| НФТ-1 | Медианное время запуска среды | ≤ 20 с (без кэша) | 18,3 с (30 сессий); 6,1 с (прогретый кэш) | Выполнено |
| НФТ-2 | Число параллельных сессий | ≥ 30 без деградации SLA | 30 сессий; max 34,7 с; ошибок: 0 | Выполнено |
| НФТ-3 | Сетевая изоляция | 0 успешных межсессионных соединений | 0 из 50 попыток соединений между Pod'ами labs | Выполнено |
| НФТ-4 | Отказоустойчивость | Отказ пода не нарушает управляемость | Перезапуск по пробе живости; состояние автоматически восстановлено | Выполнено |
| НФТ-5 | Аудит операций | Все критичные события зафиксированы | Loki + структурированный журнал: субъект, время, тип, статус | Выполнено |
| НФТ-6 | GitOps-сопровождение | Изменения только через запрос на слияние | 100% изменений через MR в GitLab; прямые правки заблокированы | Выполнено |
Все шесть нефункциональных требований выполнены. Наиболее значимым результатом является достижение НФТ-3 (нулевая межсессионная связность) как ключевого требования безопасности для образовательного киберполигона.
4.6 Эксплуатационный эффект автоматизации
При сравнении с ручным развёртыванием получены следующие практические эффекты. Время предоставления одной лабораторной среды сократилось с ~15–20 минут ручного труда администратора (создание пространства имён, настройка политик, запуск подов) до 18,3 с автоматического выполнения. Доля ручных операций в процессе релиза конфигурации снизилась до нуля: все изменения проходят через GitOps-конвейер. Предсказуемость релизов возросла: откат на предыдущую стабильную ревизию выполняется командой отката helm rollback за 3–5 секунд. Аудируемость изменений обеспечена на уровне каждого коммита в GitLab с привязкой к MR и CI-результатам.
4.7 Ограничения исследования
Результаты получены на стенде ограниченного масштаба (3 узла, 30 параллельных сессий) и не претендуют на прямую экстраполяцию без адаптации на кластеры с числом параллельных сессий более 100, гетерогенную инфраструктуру с различными профилями хранилища и сети, а также на сценарии с жёсткими регуляторными требованиями к криптографическому контролю (ГОСТ). Для производственного внедрения необходим этап пилотной эксплуатации с локальной калибровкой SLO и стресс-тестированием на целевом объёме нагрузки.
4.8 Перспективы развития
Приоритетными направлениями расширения платформы являются: внедрение автоматического масштабирования на основе метрик пользовательской нагрузки (KEDA для событийно-управляемого масштабирования); реализация декларативных политик (политики как код) через OPA/Gatekeeper и автоматизированный контроль соответствия требованиям; расширенная аналитика учебной активности и прогресса обучающихся; интеграция с корпоративной IDM/SSO (LDAP, Active Directory) для автоматической синхронизации ролей; расширение каталога безопасных шаблонов лабораторных окружений для различных дисциплин ИБ.
4.9 Вывод по главе
Апробация подтвердила, что предложенная архитектура и GitOps-процесс развёртывания обеспечивают требуемый баланс между безопасностью (НФТ-3 выполнен: 0 межсессионных соединений из 50 попыток), скоростью предоставления среды (НФТ-1 выполнен: 18,3 с < 20 с) и эксплуатационной управляемостью (НФТ-6 выполнен: 100% изменений через GitOps). Все шесть нефункциональных требований выполнены. Цели ВКР достигнуты.