Завершення підтримки 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. Існує багато варіантів контролерів Ingress, які відповідають потребам різних користувачів і випадків використання. Деякі з них призначені для конкретних хмарних провайдерів, а інші мають більш загальне застосування.
Ingress NGINX був контролером Ingress, розробленим на початку історії проєкту Kubernetes як приклад реалізації API. Він став дуже популярним завдяки своїй надзвичайній гнучкості, широкому набору функцій та незалежності від будь-якого конкретного хмарного провайдера чи провайдера інфраструктури. З тих пір групами спільноти в межах проєкту Kubernetes, а також постачальниками рішень cloud native було створено багато інших контролерів Ingress. Ingress NGINX залишається одним із найпопулярніших, його використовують у багатьох хостингових платформах Kubernetes та незліченних кластерах незалежних користувачів.
Історія та виклики
Широта та гнучкість Ingress NGINX спричинили труднощі із супроводом. Зміни в очікуваннях щодо програмного забезпечення cloud native також додали складнощів. Те, що колись вважалося корисними опціями, іноді почало розглядатися як серйозні недоліки безпеки, наприклад, можливість додавати довільні директиви конфігурації NGINX за допомогою анотацій «snippets». Вчорашня гнучкість стала сьогоднішнім непереборним технічним боргом.
Незважаючи на популярність проєкту серед користувачів, Ingress NGINX завжди мав проблеми з недостатньою або ледь достатньою кількістю супровідників. Протягом багатьох років над проєктом працювали лише одна або дві особи, які займалися розробкою у вільний час, після роботи та у вихідні. Минулого року супровідники Ingress NGINX оголосили про свої плани поступово згорнути Ingress NGINX і розробити контролер на заміну разом зі спільнотою Gateway API. На жаль, навіть це оголошення не викликало додаткового інтересу до допомоги в супроводі Ingress NGINX або розробці InGate на заміну. (Розробка 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. Додаткові варіанти можуть бути доступні у постачальників, з якими ви працюєте.
Це дзеркало оригінальної статті.