NGINX: миграция с Ingress Controller на Gateway API

Текущее положение дел: F5 NGINX Ingress Controller

Экосистема Kubernetes переживает серьёзную трансформацию в подходах к организации сетевого взаимодействия: традиционный Ingress API с его аннотациями постепенно уступает место более развитому Gateway API. Эту перемену подстёгивает растущая сложность современных приложений и необходимость в более гибком управлении трафиком. NGINX, признанный лидер в области доставки приложений, находится в авангарде этого перехода — компания предлагает как F5 NGINX Ingress Controller (NIC) для текущих и перспективных задач, так и F5 NGINX Gateway Fabric (NGF) для сложных сценариев развёртывания.

Сравнение NGINX Ingress Controller и NGINX Gateway Fabric

Kubernetes долгое время опирался на Ingress-контроллеры для управления внешним трафиком. NGINX Ingress Controller с открытым исходным кодом снискал широкую популярность благодаря высокой производительности, надёжности и богатому набору возможностей: HTTP/HTTPS-маршрутизации, терминации SSL и балансировке нагрузки. NGINX Ingress Controller продолжает развиваться, однако потребности в управлении трафиком в Kubernetes-развёртываниях становятся всё сложнее — это требует новых подходов.

Преимущества NGINX Ingress Controller

Зрелость и стабильность. NGINX Ingress Controller — проверенное решение с долгой историей надёжной работы.

Расширенные возможности. Контроллер обеспечивает гибкое управление трафиком: балансировку нагрузки на уровнях L4 и L7, ограничение частоты запросов и защиту от каскадных сбоев (circuit breaking).

Безопасность. Встроенный межсетевой экран веб-приложений (Web Application Firewall, WAF) на базе NGINX App Protect, защита от DDoS-атак и надёжные механизмы аутентификации.

Операционная прозрачность. Детальное журналирование и интеграция с инструментами наблюдаемости, нативными для облачных сред, — Prometheus и Grafana.

Будущее: Gateway API и F5 NGINX Gateway Fabric

Gateway API — это значительный шаг вперёд в развитии сетевого взаимодействия Kubernetes: он устраняет ограничения Ingress API, предлагая более гибкую, расширяемую и мощную модель. NGINX принял этот курс и выпустил NGINX Gateway Fabric с открытым исходным кодом — реализацию Gateway API.

Обзор NGINX Gateway Fabric

NGINX Gateway Fabric построен на основе открытого дата-плейна (data plane) NGINX и реализует Kubernetes Gateway API, обеспечивая сетевое взаимодействие для Kubernetes-приложений. В его основе лежит ролевая модель API, которая позволяет командам в многотенантной среде управлять инфраструктурой в режиме самообслуживания. Кроме того, одни и те же дата-плейн и контрол-плейн (control plane) можно использовать в любой гибридной или мультиоблачной среде Kubernetes, сохраняя при этом разделение плоскостей для повышения безопасности, гибкости и надёжности.

Контрол-плейн представляет собой Kubernetes-контроллер, построенный с помощью библиотеки controller-runtime. Он работает как Deployment и управляет ресурсами дата-плейна NGINX. Отслеживая изменения ресурсов Gateway API, а также объектов Services, Endpoints и Secrets, контрол-плейн автоматически обрабатывает провизионирование ресурсов и их конфигурацию.

Поды дата-плейна NGINX могут разворачиваться как в виде самостоятельного Deployment, так и в виде DaemonSet. Каждый под содержит контейнер NGINX, в котором работают как сам процесс NGINX, так и открытый NGINX Agent.

На диаграмме ниже показана архитектура и принцип работы NGINX Gateway Fabric.

Ключевые преимущества NGINX Gateway Fabric

Гибкость и расширяемость. NGINX Gateway Fabric поддерживает несколько протоколов (HTTP, TCP, gRPC и другие) и предоставляет встроенную поддержку продвинутых сценариев развёртывания — сине-зелёного (blue-green) и канареечного (canary) выпуска.

Ролевая модель. Разграничение ролей для поставщиков инфраструктуры, операторов кластера и разработчиков приложений повышает управляемость и уровень безопасности.

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

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

Расширенная выразительность и дополнительные возможности. API предоставляет более выразительные средства для маршрутизации и управления трафиком: поддержку сопоставления по заголовкам (header-based matching), взвешивания трафика и более сложных правил маршрутизации прямо «из коробки», без необходимости прибегать к аннотациям конкретного вендора.

Инструменты для миграции

Переход между Ingress-контроллерами — непростая задача, поскольку разные вендоры используют разные аннотации. Переход с Ingress-контроллера на Gateway API, например NGF, сопряжён с похожими трудностями, хотя переход между реализациями одного Gateway API значительно проще.

Отличной отправной точкой станет ingress2gateway — проект с открытым исходным кодом, разработанный сообществом Kubernetes. Являясь подпроектом Gateway API SIG-Network, ingress2gateway призван упростить переход с Kubernetes Ingress на Kubernetes Gateway API. Инструмент автоматически преобразует существующие ресурсы Ingress — включая многие аннотации и конфигурации, специфичные для конкретного провайдера, — в соответствующие ресурсы Gateway API: Gateway, GRPCRoute, HTTPRoute и BackendTLSPolicy.

F5 NGINX разработала провайдер для Kubernetes-проектов NGINX (NGINX Ingress Controller и NGINX Gateway Fabric). Провайдер NGINX в составе ingress2gateway позволяет конвертировать ресурсы NGINX Ingress Controller в ресурсы Gateway API для последующего использования с NGINX Gateway Fabric.

Даже если вы используете community-проект ingress-nginx, после миграции на Gateway API с помощью соответствующего провайдера вы сможете перейти на NGINX Gateway Fabric. В конце концов, переносимость — одна из ключевых целей Gateway API.

Важно понимать: ingress2gateway — не полноценное сквозное решение для миграции. Преобразованные ресурсы потребуют ручной проверки, функционального тестирования и дополнительных изменений конфигурации под конкретную среду.

Ключевые возможности ingress2gateway

Конвертация ресурсов. ingress2gateway умеет преобразовывать базовые ресурсы Kubernetes Ingress и связанные с ними объекты Services в эквивалентные ресурсы Gateway API.

Поддержка аннотаций. Инструмент обрабатывает различные NGINX-специфичные аннотации, транслируя их в соответствующие ресурсы Gateway API.

Среди поддерживаемых аннотаций:

nginx.org/ssl-services — для SSL/TLS-соединений с бэкендом, преобразуется в BackendTLSPolicy.
nginx.org/grpc-services — для gRPC-соединений с бэкендом, преобразуется в GRPCRoute.
nginx.org/websocket-services — для WebSocket-соединений с бэкендом; генерирует информационное уведомление.
nginx.org/proxy-hide-headers и nginx.org/proxy-set-headers — для модификации заголовков; преобразуются в фильтры ResponseHeaderModifier и RequestHeaderModifier объекта HTTPRoute соответственно.
nginx.org/rewrites — для переписывания URL, преобразуется в фильтр URLRewrite объекта HTTPRoute.
nginx.org/redirect-to-https и ingress.kubernetes.io/ssl-redirect — для редиректов на SSL/HTTPS; преобразуются в фильтр RequestRedirect объекта HTTPRoute.

Полный список аннотаций и их соответствий ресурсам Gateway API можно найти в репозитории провайдера NGINX на GitHub. Некоторые ресурсы, в частности virtualServer, VirtualServerRoute и transport server, пока не поддерживаются, однако запланированы к реализации в будущем.

Применение и преимущества

Использование ingress2gateway совместно с провайдером NGINX сводится к двум основным сценариям:

Конвертация из кластера:

ingress2gateway print --providers=nginx

Эта команда конвертирует ресурсы NGINX Ingress Controller непосредственно из Kubernetes-кластера.

Конвертация из файла:

ingress2gateway print --providers=nginx --input-file=nginx-ingress.yaml

Эта команда конвертирует ресурсы из YAML-файла.

Подробные инструкции по использованию приведены в README основного проекта.

Среди преимуществ ingress2gateway можно выделить следующие:

Упрощённая миграция. Автоматизация конвертации снижает сложность перехода на Gateway API и уменьшает объём ручной работы.

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

Поддержка продвинутых возможностей. ingress2gateway транслирует сложные функции NGINX Ingress Controller — конфигурации SSL/TLS, модификации заголовков и другие — в соответствующие конструкции Gateway API.

Процесс миграции с Ingress Controller на Gateway API

Даже при использовании ingress2gateway с провайдером NGINX переход на Gateway API требует тщательного планирования. Процесс включает несколько этапов:

Подготовка к миграции. Задокументируйте текущую конфигурацию: объекты Ingress и используемые аннотации. Определите цели миграции и критерии успеха.

Установка и настройка. Разверните NGINX Gateway Fabric рядом с действующим Ingress-контроллером. Конвертируйте конфигурации Ingress в ресурсы Gateway API.

Тестирование и валидация. Проведите комплексное функциональное и нагрузочное тестирование. Проверьте работу средств безопасности и контролируйте метрики производительности.

Переключение трафика. Постепенно переводите трафик на NGINX Gateway Fabric, например с помощью канареечных выпусков.

Финальная очистка. После подтверждения стабильной работы выведите из эксплуатации старый Ingress-контроллер.

Вклад в проект и расширяемость

Проект ingress2gateway открыт для участия сообщества — в первую очередь в части добавления поддержки новых аннотаций NGINX Ingress Controller. Участники могут руководствоваться инструкциями в репозитории для реализации логики конвертации, написания тестов и обновления документации.

Используя ingress2gateway, организации могут упростить переход на Gateway API и воспользоваться его гибкостью, расширяемостью и продвинутыми возможностями управления трафиком. Этот инструмент будет ценным подспорьем для тех, кто стремится модернизировать сетевую инфраструктуру Kubernetes на базе NGINX Ingress Controller и NGINX Gateway Fabric.

Заключение

Переход от Ingress-контроллеров к Gateway API — значимый шаг в развитии сетевого взаимодействия Kubernetes. NGINX готова сопровождать этот переход: NGINX Ingress Controller закрывает актуальные потребности, а NGINX Gateway Fabric — перспективные. Благодаря ingress2gateway организации могут упростить миграцию на Gateway API и в полной мере воспользоваться его гибкостью, расширяемостью и развитыми возможностями управления трафиком. Для тех, кто хочет модернизировать сетевую инфраструктуру Kubernetes с помощью NGINX Ingress Controller и NGINX Gateway Fabric, этот инструмент станет незаменимым помощником.

Используете ли вы сейчас NGINX Ingress Controller или только планируете перейти на Gateway API — NGINX предоставляет всё необходимое: инструменты, поддержку и технологии для уверенной работы в меняющихся условиях. По мере зрелости Kubernetes NGINX остаётся надёжным партнёром в создании производительных, защищённых и масштабируемых решений для доставки приложений.

Начало работы

Узнайте подробнее о NGINX Ingress Controller и его возможностях.
Изучите NGINX Gateway Fabric и его роль в будущем сетевого взаимодействия Kubernetes.
Присоединяйтесь к сообществу NGINX и обсуждайте задачи и стратегии в области Kubernetes-сетей.

Логотип NGINX и приглашение к участию в сообществе