Ingress NGINX «помирає»: чому це важливо і який план дій для користувачів AKS

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Cьогодні без довгих вступів, бо новина справді критична. Community-версія Ingress NGINX Engine припиняє своє існування.

Якщо ви використовуєте AKS (Azure Kubernetes Service), для вас це означає, що план міграції потрібен був ще «на вчора». Це звучить як клікбейт, але давайте розберемося без паніки: що сталося, чому Gateway API — це майбутнє, і які є три конкретні шляхи вирішення проблеми.

Що взагалі відбувається

Офіційний анонс Kubernetes спільноти безапеляційний: проект закривають, щоб «пріоритезувати безпеку екосистеми».

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

Дедлайн: Березень 2026 року. Після цієї дати — жодних фіксів багів, жодних оновлень і, що найголовніше, жодних патчів безпеки. Продовжувати використовувати його далі — це свідомо залишити дірку в безпеці кластера.

Крок 1: Перевірка на «пацієнта»

Можливо, ви це навіть не використовуєте? Давайте перевіримо прямо зараз. Запустіть у терміналі:

kubectl get pods --all-namespaces | grep ingress-nginx

Якщо список подів є — читаємо далі.

Ера Gateway API: Чому це добре

Ми не просто втрачаємо інструмент, індустрія переходить на новий стандарт — Gateway API.

Старий Ingress API нагадував величезний спільний Google Doc, де і адміни платформи, і розробники застосунків правили один і той самий файл конфігурації. Постійні конфлікти анотацій, ризик покласти весь кластер однією правкою — знайомо?

Gateway API вирішує це через чіткий поділ ролей:

  1. Platform Admins: Керують об’єктом Gateway (сам лодбалансер, порти, TLS-сертифікати).
  2. Developers: Керують HTTPRoute (маршрутизація трафіку до конкретного сервісу).

Більше ніяких «магічних» анотацій для канаркових релізів чи маніпуляцій із хедерами. Все це тепер стандартизовано «з коробки».

Варіанти міграції для AKS: Обираємо стратегію

Що робити конкретно вам в Azure? Є три основні шляхи.

Варіант 1: «Зробіть мені просто» (App Routing Add-on)

Це нативний аддон від Microsoft для AKS.

  1. Як це працює: Під капотом там той самий NGINX. АЛЕ: Microsoft офіційно бере на себе його підтримку. Тобто ви захищені від EOL ком’юніті-версії, бо патчити і оновлювати його будуть інженери Azure.
  2. Бонус: Microsoft планує плавно перевести цей аддон на Gateway API у майбутньому. Ви просто користуєтесь managed-сервісом і отримуєте міграцію «автоматом».
  3. Для кого: Для тих, хто хоче «поставити і забути».

Варіант 2: «Azure Native Power» (Application Gateway for Containers — AGC)

Якщо ви користувалися AGIC (Application Gateway Ingress Controller), то AGC — це його еволюція, побудована повністю на Gateway API.

  1. Як це працює: Це потужний зовнішній Azure Load Balancer, підключений до Kubernetes.
  2. Фічі: Ви виносите важку роботу (WAF, складний раутінг) за межі кластера. Це ентерпраз-рівень.
  3. Для кого: Для тих, кому потрібен Web Application Firewall (WAF) і максимальна інтеграція з екосистемою Azure.

Варіант 3: «Повний контроль» (Istio + Gateway API)

Найпопулярніший Service Mesh тепер має повну підтримку Gateway API.

  1. Як це працює: Ви отримуєте повний контроль над трафіком всередині кластера.
  2. Фічі: mTLS, складна політика безпеки між мікросервісами, A/B тестування, глибока метрика.
  3. Для кого: Для high-load систем, яким потрібен fine-grained контроль над кожним запитом.

Підсумок

Community Ingress NGINX йде в історію. Це не привід для смутку, а можливість перейти на більш дорослі інструменти.

Ваш вибір залежить від потреб:

  1. App Routing Add-on — найбезпечніший і найпростіший шлях.
  2. AGC — якщо потрібна потужність Azure (WAF, Load Balancing).
  3. Istio — якщо потрібен Service Mesh і контроль всередині кластера.

Який шлях плануєте обрати ви? Пишіть у коментарях, цікаво подивитися статистику по українському сегменту.

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

в мене для куба istio й haproxy коли треба інгрес

Прочитав ту новину, й пішов пити кавуню.

Для aks треба брати те що пропонує ажур тобто agic, ніколи не доганяв цей тренд вивалювати лаве за менеджед і потім економити на сірниках, але таке вже

А взагалі тренд намалювався коли популярні опенсорс проекти набравши популярності й вилізши нагору, забирають за собою драбину. Не здивуюсь якщо скоро зникнуть опенсорсні каліко, циліум, сертменеджер і решта інструментів що стали стандартними

Це прекрасно)
Або МС або МС але дорожче )
Або застрелиться з ISTIO (до чого тут він до ingres питання)
Envoy, Traefik, HA, Consul.

Якщо забули, чи не знали, замість Nginx Ingress Controller тепер буде (точніше, вже є) Nginx Gateway Fabric для роботи з Gateway API. Але сам ще не щупав його.

він досить сирий, краще вже Envoy або Traefik

Підписатись на коментарі