Давайте проведём небольшой эксперимент. Откройте любой production-кластер и посчитайте, сколько у вас Ingress. Теперь посмотрите не на количество объектов. Посмотрите на annotations. С высокой вероятностью вы увидите что-то подобное:
annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/proxy-read-timeout: "600" nginx.ingress.kubernetes.io/proxy-send-timeout: "600" nginx.ingress.kubernetes.io/use-regex: "true" nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "10"
А теперь честно ответьте на один вопрос:
Вы действительно используете Kubernetes Ingress?
Или вы используете NGINX API, который по какой-то исторической причине записывается в Kubernetes annotations?
Для многих больших компаний это довольно неприятный вопрос.
Потому что ingress-nginx много лет был компонентом «по умолчанию». Его ставили в новый кластер почти автоматически. Затем вокруг него выросла маршрутизация production-трафика, CI/CD, Helm charts, cert-manager, мониторинг и десятки специфичных настроек.
Теперь поддержка ingress-nginx завершилась.
И для многих команд это будет первый момент за последние годы, когда придётся не просто обновить Helm chart, а подумать:
А как вообще должна выглядеть маршрутизация трафика в нашей Kubernetes-платформе следующие пять лет?
На мой взгляд, именно здесь начинается история Gateway API.
Ingress-NGINX заканчивается, но проблема появилась гораздо раньше
Важно разделять две вещи. Kubernetes Ingress никуда не исчезает. NGINX тоже никуда не исчезает. Закончилась история конкретного проекта ingress-nginx. Но, если честно, главная проблема давно была не в поддержке самого контроллера. Проблема появилась в тот момент, когда Ingress начали использовать для задач, для которых он изначально был слишком простым.
Когда у вас пять сервисов, всё прекрасно, но затем компания растёт, появляется 30 команд, потом 300 сервисов, несколько Kubernetes-кластеров и тд.
И внезапно простой Ingress превращается в набор annotations, которые знают только несколько инженеров.
Я видел инфраструктуры, где вопрос:
«Зачем здесь эта annotation?»
имел вполне стандартный ответ:
«Не знаем. Она была до нас».
Это и есть настоящий технический долг, не старый Kubernetes, не старый NGINX, а инфраструктурная логика, которую невозможно объяснить без знания истории компании.
Gateway API — это не новый Ingress
Самая частая ошибка — смотреть на Gateway API вот так:
думать, что теперь нужно просто переписать YAML. На самом деле Gateway API интересен другим. Он позволяет разделить инфраструктуру и приложения.
Упрощённо модель выглядит так:
Но ценность здесь не в количестве объектов. Представим крупную компанию.
Platform-команда отвечает за:
Load BalancerTLSNetworkSecurityObservability
Команда разработки хочет сделать:
/api → orders-service
В старом мире эти две ответственности часто пересекаются. В новом их можно разделить. Platform-команда создаёт Gateway, а команда приложения создаёт HTTPRoute. И это, на мой взгляд, главный аргумент в пользу Gateway API для больших Kubernetes-платформ. Не новые возможности routing, а нормальная модель ответственности.
Сценарий №1. «У нас 400 Ingress, мигрируем всё»
Это плохой сценарий.
Но именно так часто начинается разговор.
У ingress-nginx закончилась поддержка, у нас 400 Ingress, нужно перевести их на Gateway API.
Первое желание инженера — написать конвертер. И технически часть миграции действительно можно автоматизировать, но через несколько дней оказывается, что 350 Ingress простые: host -> path -> service, а остальные 50 содержат всю боль компании, где-то regex, где-то нестандартный rewrite, где-то canary и тд. А один сервис работает только потому, что в ConfigMap ingress-nginx пять лет назад добавили глобальную настройку.
Поэтому правильная миграция выглядит не так:
А примерно так:
Автоматическая конвертация YAML здесь может помочь, но настоящая работа начинается после неё. Нужно проверить, что новый routing ведёт себя так же, как старый. Особенно если в инфраструктуре годами использовались nginx-specific возможности.
Сценарий №2. Миграция без миграции
Это мой любимый подход. Представим компанию с десятками Kubernetes-кластеров и сотнями приложений. Полностью переписывать старую инфраструктуру дорого, поэтому команда делает следующее. В существующих кластерах продолжает работать старый ingress. Рядом появляется Gateway API.
Получается такая архитектура:
И дальше происходит важная вещь.
Никто не объявляет миграцию 500 сервисов.
Просто новые сервисы начинают использовать Gateway API.
Новый внутренний Helm chart больше не создаёт:
kind: Ingress
Он создаёт Route. Внутренняя документация описывает Gateway API. Platform-команда строит стандартный способ публикации сервисов вокруг новой модели. Через полгода оказывается, что большинство новых приложений уже не зависит от старого ingress. Через год часть старых сервисов естественным образом была переписана или выведена из эксплуатации. И вместо огромного migration project появляется постепенное уменьшение технического долга. На мой взгляд, именно так в больших компаниях и стоит внедрять подобные технологии.
Миграция начинается не с Gateway Controller
Это ещё одна ошибка, которую я часто вижу в подобных проектах. Инженеры начинают выбирать: Envoy? Traefik? NGINX Gateway Fabric? Но выбор реализации — это далеко не первый вопрос.
Первый вопрос:
Что именно сейчас делает наш ingress-nginx?
Я бы начал с аудита, не «сколько Ingress», а какие возможности реально используются.
Сколько уникальных annotations? Где regex? Где canary? Какие timeout отличаются от стандартных? Какие правила маршрутизации существуют вне самих Ingress?
После этого почти всегда появляется понятная картина. Большая часть инфраструктуры оказывается простой, а вся сложность находится в небольшом количестве сервисов и именно с ними нужно работать отдельно.
Почему это особенно актуально для российских компаний
Я не думаю, что в России все одновременно перейдут на Gateway API. Часть компаний выберет другой ingress controller и это абсолютно рационально.
Если задача звучит так:
Нужно быстро заменить неподдерживаемый компонент с минимальными изменениями.
то архитектурная революция может быть совершенно не нужна, но крупные компании будут смотреть на эту историю шире. Потому что Kubernetes в таких организациях давно перестал быть просто набором кластеров, он стал внутренней платформой.
А значит, проблема звучит уже не так:
«Как опубликовать сервис?»
А так:
«Как дать сотням разработчиков возможность самостоятельно управлять маршрутизацией, но при этом не давать им доступ к сетевой инфраструктуре?»
И вот здесь Gateway API выглядит значительно интереснее. Он позволяет Platform-команде управлять Gateway, а командам приложений — управлять своими маршрутами. Это гораздо ближе к тому, как реально устроены большие компании.
Самый важный момент: не создавайте новый технический долг
Если бы мне сегодня досталась Kubernetes-платформа, завязанная на ingress-nginx, я бы не начинал с миграции всего.
Я бы сначала сделал одну вещь.
Перестал бы создавать новые зависимости от старой модели.
Старые приложения продолжают работать, никто не ломает production.
Но новые сервисы получают стандартную модель:
И дальше время начинает работать на платформу. Каждый новый сервис появляется уже в новой архитектуре. Каждый старый можно мигрировать отдельно. И в какой-то момент ingress-nginx перестаёт быть критическим компонентом, он становится просто ещё одним legacy dependency, а это уже совершенно другая ситуация.
Вместо вывода
Я не думаю, что Gateway API полностью вытеснит Ingress. Ingress ещё долго будет использоваться. Он простой и понятный, и для огромного количества задач его достаточно, но Gateway API появился в тот момент, когда Kubernetes стал меняться.
Раньше Kubernetes-кластером управляла одна команда, теперь Kubernetes часто является платформой для десятков или сотен команд.
И старая модель — вот вам Ingress, вот annotations, разбирайтесь, начинает выглядеть слишком простой для современных production-платформ, поэтому окончание истории ingress-nginx я бы не воспринимал только как проблему. Да, кому-то придётся мигрировать и разбираться с legacy, но одновременно это хороший повод наконец открыть свои Ingress и посмотреть на них свежим взглядом. Возможно, у вас там не 400 Kubernetes-ресурсов, а 400 маленьких исторических артефактов, в которых записано, как компания последние пять лет училась направлять HTTP-трафик. И Gateway API — это шанс перестать переносить эту историю в следующий контроллер, а начать строить следующую версию платформы немного аккуратнее.
ссылка на оригинал статьи https://habr.com/ru/articles/1076928/