CNCF отказывается от использования контроллера Ingress Nginx для Kubernetes

Запускаете контроллер Ingress Nginx для своих кластеров Kubernetes? У вас есть время до марта, чтобы перейти на Gateway API или какой-либо другой вариант, как объявил на прошлой неделе Фонд Cloud Native Computing Foundation KubeCon+CloudNativeCon North America.

Это была новость, о которой многие знали, но все равно были удивлены, особенно о том, что от них требовали быстрого поворота событий.

«Итак, сегодня по конференции слоняется много людей в поисках замены, потому что Ingress является входным контроллером по умолчанию для Kubernetes», — сказал вице-президент HAProxy по проектированию и эксплуатации Фрэнк Манчина в интервью TNS на мероприятии.

Сеть Kubernetes SIG и Комитет по реагированию на проблемы безопасности планируют прекратить работу Ingress Nginx в марте 2026 года. После этого программное обеспечение не будет поддерживаться: никаких дальнейших выпусков, исправлений ошибок и обновлений для устранения каких-либо уязвимостей безопасности.

Код останется на GitHub для архивирования, а также для поддержки программного обеспечения, такого как оператор Helm.

Те, кто продолжает эксплуатировать контроллер после марта, делают это на свой страх и риск.

Хотите знать, работает ли в вашем кластере Ingress Nginx? В командной строке с правами администратора кластера введите следующее:

kubectl get pods \—all-namespaces \—selector app.kubernetes.io/name=ingress-nginx 1 kubectl get pods \—all-namespaces \—selector app.kubernetes.io/name=ingress-nginx

Сеть для Kubernetes

Поддержка сети в Kubernetes появилась поздно. CNCF работала над Gateway API четыре года, выпустив первую версию в прошлом году. Шлюз направляет трафик в кластер и за его пределы, как трафик уровня 4 (уровень TCP/IP), так и трафик уровня 7 (для трафика приложений).

Сам Ingress представляет собой набор правил API для направления внешнего сетевого трафика на доступ к кластеру. Контроллер Ingress Nginx родился как проект Kubernetes. В качестве основы он использовал обратный прокси-сервер Nginx с открытым исходным кодом, которым теперь управляет сетевая компания F5 Inc. Контроллер Ingress Nginx стал одним из множества контроллеров, появившихся для реализации Ingress API.

Однако группы по сети и безопасности Kubernetes, отвечающие за проект, обнаружили, что поддерживать его сложно. Найти людей, которые могли бы помочь поддерживать базу кода, было непросто, особенно после того, как проект Gateway API был запущен. Кроме того, возможность добавлять произвольные директивы конфигурации NGINX, известные как фрагменты, стала проблемой безопасности.

API шлюза, созданный на основе набора пользовательских определений ресурсов (CRD) Kubernetes, был представлен в 2023 году и с тех пор стал предпочтительным и перспективным способом CNCF для осуществления входящего (входящего) и исходящего (исходящего) трафика для Kubernetes.

«Со спецификацией Gateway API у вас гораздо больше спецификаций и контроля. Вот почему люди, вероятно, перейдут на нее. И Kubernetes развивается очень, очень быстро, и эта спецификация, похоже, набирает наибольшую популярность», — пояснил Манчина далее.

Ответы компаний

Поставщик программного обеспечения для обратного прокси-сервера HAProxy Technologies LLC — одна из компаний, откликнувшихся на инициативу Gateway API. Он уже давно предлагает HAProxy Ingress и расширил поддержку Gateway API с помощью недавно выпущенного HAProxy Unified Gateway — бесплатного продукта с открытым исходным кодом, обеспечивающего нативную маршрутизацию приложений Kubernetes как для Gateway API, так и для Ingress.

«Мы увидели, что у нас есть клиенты, рабочий процесс которых уже установлен с помощью правил Ingress, и они не хотят его менять», — сказал директор по продукту HAProxy Батист Ассманн в интервью TNS.

Unified Gateway предназначен для обеспечения возможности легкого перехода к API шлюза, если позволяет время. Или запускайте оба параллельно.

«Вместо того, чтобы иметь один продукт для правил Ingress и один продукт для API-интерфейсов шлюза и предлагать людям выбирать тот или иной вариант, стратегия состоит в том, чтобы новый продукт также поддерживал правила Ingress, чтобы люди могли начать использовать правила Ingress, а затем переключиться на Ghetto API, когда они будут готовы», — сказал Ассманн.

По его мнению, переход с одного на другой может потребовать некоторой работы из-за различий в архитектуре.

В то время как Ingress работает на модели центрального контроллера, API шлюза работает на модели оператора Kubernetes. «Это совершенно другой способ настройки», — добавил он.

API Gateway обеспечивает превосходное разделение задач, пояснил далее Манчина. Например, он различает объекты, которыми может управлять команда платформы, те, которые контролируются командой эксплуатации, и те, которыми управляет группа приложений.

HA Proxy также работает, перенося выбранное количество аннотаций Nginx на единый шлюз.

Другие платформы, предлагающие поддержку Gateway API, включают Nginx Gateway Fabric (см. подробный анализ TNS Janakiram MSV здесь), а также Envoy, Istio, Cilium и собственный KGateway от CNCF.

ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джоаб Джексон — старший редактор The New Stack, специализирующийся на облачных вычислениях и системных операциях. Он освещал вопросы ИТ-инфраструктуры и ее развития более 30 лет, в том числе работал в IDG и Government Computer News. До этого он… Подробнее от Джоава Джексона

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *