Kubernetes Gateway API замість Ingress: коли варто планувати міграцію

Проєкт Kubernetes рекомендує Gateway API для нових сценаріїв маршрутизації, тоді як Ingress API заморожений: його не видаляють, але функціонально більше не розвивають. Міграція потрібна не кожному кластеру негайно. Вона виправдана, коли команді потрібні чіткий поділ ролей, переносимі правила маршрутів, розширені протоколи або менша залежність від специфічних анотацій контролера.

Чому Ingress не зникає, але вже не росте

Ingress є стабільним API Kubernetes для публікації HTTP- і HTTPS-сервісів. Він підтримує хости, шляхи, TLS і бекенди. Існуючі ресурси продовжать працювати, а проєкт не планує видаляти API. Тому заміна всіх Ingress під час найближчого спринту не є обов’язковою вимогою.

Проблема в іншому: базова модель надто вузька для сучасних сценаріїв. Контролери почали реалізовувати додаткові можливості через власні анотації. Тайм-аути, перенаправлення, переписування, canary-розподіл і політики відрізняються між постачальниками, через що маніфести важко переносити й перевіряти.

Gateway API розділяє інфраструктуру та маршрути

Gateway API складається з кількох пов’язаних ресурсів. GatewayClass описує клас реалізації, який зазвичай контролює постачальник або платформна команда. Gateway визначає конкретну точку входу, адреси, порти й listeners. HTTPRoute задає правила HTTP-маршрутизації до сервісів.

Такий поділ відображає реальні ролі. Інфраструктурний провайдер керує реалізацією, оператор кластера — шлюзом і сертифікатами, а команда застосунку — маршрутами у своєму просторі імен. Ingress часто змішував ці рішення в одному об’єкті та наборі анотацій.

Приєднання Route є двостороннім

HTTPRoute посилається на Gateway через parentRefs, але Gateway також визначає, які маршрути має право приймати конкретний listener. Можна дозволити тільки той самий namespace, вибрані простори за мітками або інші контрольовані варіанти. Це зменшує ризик, що команда випадково приєднає маршрут до чужого публічного шлюзу.

Доступ до бекендів за межами namespace теж потребує явного дозволу через ReferenceGrant. Модель змушує фіксувати перехресну довіру як ресурс, а не приховувати її в широких RBAC-правах або документації.

HTTPRoute описує більше без приватних анотацій

Стандартний HTTPRoute підтримує зіставлення за хостом, шляхом, заголовками й параметрами, фільтри, кілька backendRefs, ваги та тайм-аути в межах підтримуваної версії. Реалізація звітує статус і умови прийняття маршруту, що допомагає відрізнити створений YAML від фактично застосованої конфігурації.

Не кожна функція однаково стабільна. Gateway API має Standard і Experimental channels. Перед використанням поля потрібно перевірити його статус у версії специфікації та підтримку конкретним контролером. Копіювати приклад із нової документації до старої реалізації небезпечно.

Версія Gateway API не дорівнює версії Kubernetes

API встановлюється через CustomResourceDefinitions і контролер, тому його оновлення не завжди вимагає оновлення всього кластера. Наприклад, офіційний матеріал про Gateway API v1.5 зазначав можливість роботи з Kubernetes 1.30 і новішими. Але постачальник керованого кластера може мати власний життєвий цикл.

Команда повинна перевіряти чотири версії: Kubernetes, CRD Gateway API, контролер та його реалізацію conformance profile. Слово «підтримує Gateway API» без точних версій недостатнє для плану міграції.

Conformance важливіша за логотип

Gateway API має набори обов’язкових і додаткових можливостей, а реалізації можуть проходити перевірку відповідності. Це дає кращу основу для переносимості, ніж неформальний список анотацій. Проте два сумісні контролери можуть мати різні розширення, операційні моделі та інтеграції з хмарою.

Перед вибором перевірте потрібні протоколи, підтримку TLS, політик, спостережуваності, статичної адреси й інтеграції з DNS. Переносимий маршрут не гарантує однакової вартості або поведінки балансувальника.

Безпека починається з ролей

Створення Gateway може запускати зовнішній балансувальник, виділяти адресу та змінювати DNS. Такі права не варто давати кожному розробнику. Платформна команда створює дозволені GatewayClass і Gateway, а застосунки отримують обмежені права на власні Route.

Також потрібні політики для wildcard-хостів, сертифікатів, зовнішніх адрес і маршрутів за замовчуванням. Статус Accepted не доводить, що сервіс безпечний: мережеві політики, автентифікація, WAF та обмеження запитів можуть залишатися окремими шарами.

Як перенести маршрут без простою

1. Інвентаризуйте Ingress, класи та всі анотації.
2. Розділіть стандартні функції й залежності від контролера.
3. Виберіть Gateway API реалізацію та перевірте conformance.
4. Створіть тестовий Gateway з окремою адресою.
5. Перенесіть один низькоризиковий маршрут у HTTPRoute.
6. Порівняйте TLS, заголовки, тайм-аути, коди помилок і спостережуваність.
7. Перемикайте DNS або трафік поступово з можливістю відкату.
8. Видаліть старий Ingress лише після завершення періоду спостереження.

Не перекладайте анотації механічно

Одна анотація може поєднувати кілька рішень: поведінку маршруту, політику інфраструктури та параметр конкретного проксі. У Gateway API вони можуть опинитися в різних ресурсах або розширеннях. Механічний конвертер створить синтаксис, але не перевірить задум.

Для кожної функції зафіксуйте очікувану поведінку у тестах: перенаправлення, переписування шляху, cookie, балансування, health check, довгі з’єднання та максимальний розмір запиту. Саме тести, а не схожість YAML, доводять еквівалентність.

Коли залишитися на Ingress

Якщо кластер має кілька простих стабільних маршрутів, контролер підтримується, а приватні анотації не створюють проблем, термінова міграція може не окупитися. Варто натомість заборонити нові нестандартні залежності, документувати поточну конфігурацію й закласти Gateway API для наступної платформи.

Базові компоненти пояснює стаття TechPulse про Kubernetes, а матеріал про DevOps допомагає пов’язати міграцію з автоматизованими тестами та відповідальністю команд.

Gateway API — це еволюція моделі мережі Kubernetes, а не наказ негайно вимкнути Ingress. Найкращий момент переходу настає тоді, коли команда має чіткі вимоги, сумісну реалізацію та спосіб довести поведінкову еквівалентність.

Першоджерела: документація Kubernetes Ingress, вступ до Gateway API та довідник HTTPRoute.