Финальный пост цикла о миграции с Ingress-NGINX. Предыдущие посты описывали конкретные ловушки. Этот — о том, как проверить результат и снизить риск сбоев при переключении трафика.
Инвентаризация. Выгрузите все Ingress-ресурсы и составьте список уникальных аннотаций. Это покажет полный объём конфигурации, которую нужно перенести, и места, где автоматический перевод невозможен.
Теневое тестирование. Gateway API поддерживает зеркалирование трафика через фильтр
RequestMirror. Реальный трафик продолжает идти через Ingress-NGINX, а его копия параллельно обрабатывается новым Gateway. Можно сравнивать ответы и выявлять расхождения без риска для продакшена.Утилита
ingress2gateway. Инструмент от сообщества Kubernetes конвертирует Ingress-ресурсы в HTTPRoute и показывает места, где автоматический перевод невозможен. Хорошая отправная точка, но не финальный результат.Проверка приоритетов маршрутов. В Gateway API более специфичный путь имеет больший приоритет. В Ingress-NGINX логика другая. Если есть пересекающиеся маршруты, порядок их срабатывания после миграции может измениться незаметно.
Начните с одного маршрута, протестируйте его в тени, убедитесь в корректности — и только потом двигайтесь дальше. Чем больше у вас тестов, описывающих реальное поведение маршрутов, тем безопаснее переход.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженера