Автоматическое переключение на страницу технического обслуживания в системе на базе Kubernetes

Автоматическое переключение на страницу технического обслуживания в системе на базе Kubernetes

1. Предпосылки
При эксплуатации 000 000 проведение как плановых, так и внеплановых системных работ неизбежно, и во время таких работ требуется отображать пользователям страницу уведомления.
Ранее процесс ограничивался тем, что оператор публиковал объявление при каждом проведении работ. Такой подход нес в себе риск возникновения человеческой ошибки (Human Error).
Для решения этой проблемы была спроектирована и реализована функция, которая автоматизирует весь процесс — от переключения на страницу обслуживания до возврата в исходное состояние — только за счет регистрации объявления.


2. Общий процесс работы
Весь процесс работает следующим образом:

① Регистрация объявления
Когда администратор регистрирует системное объявление, он устанавливает поле «признак технического обслуживания» в значение Y, а также сохраняет время начала и окончания работ.
Эти данные являются отправной точкой всей автоматизации.

② Обнаружение планировщиком
Пакетный планировщик, реализованный с использованием @Scheduled в Spring, периодически обращается к таблице объявлений и определяет, достигло ли текущее время времени начала работ.

③ Получение информации о Pod целевого сервиса
С помощью Kubernetes Java Client выполняется получение текущей информации о Pod целевого сервиса.
Эта информация используется как основа для переключения маршрутизации трафика.

④ Генерация временной страницы обслуживания
На основе содержимого объявления (причина работ, предполагаемое время завершения и т.д.) динамически создается статическая HTML-страница обслуживания.

⑤ Сборка Docker-образа и загрузка в ECR
Созданная страница обслуживания упаковывается с использованием Dockerfile на базе Nginx.
После этого собирается Docker-образ и отправляется в AWS ECR (Elastic Container Registry).

⑥ Создание временного Pod и переключение трафика
На основе образа, размещенного в ECR, создается временный Pod для обслуживания.
Затем изменяется selector Kubernetes Service, чтобы перенаправить трафик с существующих Pod сервиса на временный Pod.
Пользователь, обращающийся к системе в этот период, увидит страницу обслуживания.

⑦ Завершение работ и автоматическое восстановление
Когда планировщик обнаруживает, что время окончания работ достигнуто, selector Service возвращается к исходным меткам Pod.
После этого временный Pod и связанные ресурсы удаляются, а образ в ECR очищается.


3. Ключевые технические моменты реализации

Использование Kubernetes Java Client
Для управления ресурсами Kubernetes из Java-приложения использовалась официальная библиотека Kubernetes Java Client.
С помощью CoreV1Api удалось программно:
• получать список Pod
• изменять selector Service
• создавать и удалять Pod


Динамическая сборка Docker-образа
Поскольку содержимое страницы обслуживания каждый раз различается, была спроектирована структура, в которой:
• данные объявления привязываются к шаблону для генерации HTML-файла
• затем файл собирается вместе с Dockerfile на базе Nginx
С использованием ProcessBuilder в Java выполнялись команды Docker CLI, и был автоматизирован весь процесс — от сборки образа до авторизации в ECR и загрузки.


Стратегия переключения трафика
Переключение трафика реализовано путем изменения label selector Kubernetes Service.
Разделяя метки существующих и временных Pod:
• можно переключить трафик без остановки сервиса, просто изменив selector
• нет необходимости изменять настройки Ingress или прокси
Этот подход прост в реализации и при этом стабилен.


Проектирование механизмов безопасности
Поскольку система является автоматизированной, важно учитывать обработку исключительных ситуаций.
Были реализованы:
• механизмы отката (rollback) на каждом этапе, чтобы сбои (например, ошибка сборки образа) не влияли на существующий сервис
• механизм принудительного восстановления на основе тайм-аута на случай, если возврат не произошел после окончания работ
• запись состояния всех этапов в базу данных для мониторинга администратором


4. Заключение
В ходе реализации стало очевидно, что Kubernetes — это не просто инструмент оркестрации контейнеров, а мощная платформа для автоматизации инфраструктуры при интеграции с Java-приложениями.
Особенно впечатлило то, что с использованием Kubernetes Java Client можно управлять инфраструктурой на уровне приложения без необходимости в отдельных скриптах или CI/CD пайплайнах.
В дальнейшем планируется продолжать расширять область автоматизации для повышения эффективности эксплуатации.

Undefined