Закінчення підтримки Ingress NGINX: що потрібно знати
Для забезпечення пріоритетності безпеки та захисту екосистеми, Kubernetes SIG Network та Комітет з реагування на загрози безпеки оголошують про майбутнє завершення підтримки Ingress NGINX. Підтримка буде продовжуватися до березня 2026 року. Після цього не буде нових випусків, виправлень помилок та оновлень для усунення будь-яких виявлених вразливостей безпеки. Наявні розгортання Ingress NGINX продовжуватимуть функціонувати, а інсталяційні артефакти залишатимуться доступними.
Ми рекомендуємо перейти на одну з багатьох альтернатив. Розгляньте можливість переходу на Gateway API, сучасну заміну Ingress. Якщо ви мусите продовжувати використовувати Ingress, багато альтернативних контролерів Ingress перелічено в документації Kubernetes. Далі ви знайдете додаткову інформацію про історію та поточний стан Ingress NGINX, а також про наступні кроки.
Про Ingress NGINX
Ingress — це оригінальний зручний спосіб перенаправлення мережевого трафіку на робочі навантаження, що виконуються в Kubernetes. (Gateway API — це новіший спосіб досягнення багатьох тих самих цілей.) Щоб Ingress працював у вашому кластері, повинен бути запущений Ingress controller. Існує багато варіантів Ingress controller, які відповідають потребам різних користувачів і випадків використання. Деякі з них призначені для конкретних хмарних провайдерів, а інші мають більш загальне застосування.
Ingress NGINX був контролером Ingress, розробленим на початку історії проєкту Kubernetes як приклад реалізації API. Він став дуже популярним завдяки своїй надзвичайній гнучкості, широкому набору функцій та незалежності від будь-якого конкретного постачальника хмарних послуг або інфраструктури. З тих пір у рамках проєкту Kubernetes спільнотами та постачальниками хмарних рішень було створено багато інших контролерів Ingress. Ingress NGINX залишається одним із найпопулярніших, його використовують у багатьох хостингових платформах Kubernetes та незліченних кластерах незалежних користувачів.
Історія та виклики
Широта та гнучкість Ingress NGINX спричинили проблеми з технічним обслуговуванням. Зміни в очікуваннях щодо хмарного програмного забезпечення також додали складнощів. Те, що колись вважалося корисними опціями, іноді почало розглядатися як серйозні недоліки безпеки, наприклад, можливість додавати довільні директиви конфігурації NGINX за допомогою анотацій «snippets». Вчорашня гнучкість стала сьогоднішнім непереборним технічним боргом.
Незважаючи на популярність проєкту серед користувачів, Ingress NGINX завжди мав проблеми з недостатнім або ледь достатнім рівнем технічного обслуговування. Протягом багатьох років над проєктом працювали лише одна або дві особи, які займалися розробкою у вільний час, після роботи та у вихідні. Минулого року адміністратори Ingress NGINX оголосили про свої плани припинити роботу над Ingress NGINX і розробити заміну контролера разом із спільнотою Gateway API. На жаль, навіть це оголошення не викликало додаткового інтересу до допомоги в підтримці Ingress NGINX або розробці InGate на заміну. (Розробка InGate ніколи не просунулася настільки, щоб створити зрілу заміну; її також буде припинено.)
Поточний стан та наступні кроки
Наразі Ingress NGINX отримує максимальну підтримку. SIG Network та Комітет з реагування на загрози безпеці вичерпали всі можливості для пошуку додаткової підтримки, щоб забезпечити стабільну роботу Ingress NGINX. З метою забезпечення безпеки користувачів ми змушені припинити роботу над проєктом.
У березні 2026 року технічне обслуговування Ingress NGINX буде припинено, а проєкт буде визнано застарілим. Після цього не буде нових випусків, виправлень помилок та оновлень для усунення будь-яких виявлених вразливостей безпеки. Репозиторії GitHub будуть переведені в режим «тільки для читання» і залишаться доступними для ознайомлення.
Наявні розгортання Ingress NGINX не будуть порушені. Артефакти проєкту, такі як чарти Helm та образи контейнерів, залишаться доступними.
У більшості випадків ви можете перевірити, чи використовуєте ви Ingress NGINX, скориставшись командою kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx з правами адміністратора кластера.
Ми хотіли б подякувати розробникам Ingress NGINX за їхню роботу над створенням та підтримкою цього проєкту — їхня відданість справі залишається вражаючою. Цей контролер Ingress обробив мільярди запитів у дата-центрах та домашніх лабораторіях по всьому світу. Багато в чому Kubernetes не був би тим, чим є зараз, без Ingress NGINX, і ми вдячні за стільки років неймовірних зусиль.
SIG Network та Комітет з реагування на загрози безпеки рекомендують усім користувачам Ingress NGINX негайно розпочати міграцію на Gateway API або інший контролер Ingress. Багато варіантів перелічено в документації Kubernetes: Gateway API, Ingress. Додаткові варіанти можуть бути доступні у постачальників, з якими ви працюєте.