Ingress NGINX Annotations to Gateway API Converter
Конвертировать аннотации Ingress NGINX в манифест Gateway API HTTPRoute перед миграцией.
Как это работает
Проект Ingress NGINX Controller официально прекратил сопровождение в марте 2026 года — новых релизов, багфиксов и патчей безопасности больше не будет, хотя существующие развёртывания продолжают работать. Kubernetes 1.35 фиксирует это как факт экосистемы, а не как эксперимент, и рекомендует переход на Gateway API как поддерживаемую замену. Проблема в том, что аннотации Ingress NGINX (rewrite-target, proxy-body-size, cors-allow-origin и десятки других) не имеют прямого эквивалента в декларативном YAML Gateway API — это не косметическая смена синтаксиса, а смена модели конфигурации. Ingress NGINX Annotations to Gateway API Converter online берёт типовые аннотации и собирает эквивалентный манифест HTTPRoute.
Обратиться к нейросети с вопросом "переведи мой Ingress в Gateway API" звучит соблазнительно, но у задачи есть конкретная техническая ловушка: Gateway API — не одна плоская спецификация, а слой из Gateway, HTTPRoute и опциональных policy-объектов, и правильное распределение логики между ними требует понимания структуры, а не текстового переписывания одного YAML в другой по аналогии.
Инструмент разбирает самые частые аннотации Ingress NGINX (nginx.ingress.kubernetes.io/rewrite-target, proxy-body-size, ssl-redirect, cors-allow-origin) и генерирует соответствующий фрагмент HTTPRoute с filters и match-правилами — с явным указанием, какие аннотации не имеют однозначного нативного эквивалента в Gateway API и потребуют либо policy-расширения конкретного контроллера, либо ручного архитектурного решения.
Частые вопросы
Означает ли retirement Ingress NGINX, что существующие кластеры сразу перестанут работать?
Нет, уже развёрнутые контроллеры продолжают функционировать, retirement означает отсутствие новых релизов, патчей безопасности и багфиксов — миграцию стоит планировать заранее, а не откладывать до критического сбоя.
Все ли аннотации Ingress NGINX имеют прямой эквивалент в Gateway API?
Нет, часть функциональности (например, некоторые продвинутые rewrite-паттерны) реализована только через специфичные для конкретного Gateway API контроллера policy-расширения, а не через базовую спецификацию — такие случаи инструмент явно помечает как требующие ручного решения.
Что такое HTTPRoute в терминах Gateway API?
Это ресурс, который описывает правила маршрутизации HTTP-трафика — matches, filters, backendRefs, примерно тот же функциональный слой, что и rules в Ingress, но с более явной и композируемой структурой.
Нужно ли одновременно менять сам Ingress controller при переходе на Gateway API?
Да, Gateway API требует контроллера, который реализует эту спецификацию (например, Envoy Gateway, Cilium, или Gateway API реализация конкретного облачного провайдера), простая замена YAML без смены runtime-контроллера работать не будет.