Экосистема Kubernetes претерпевает фундаментальные изменения в том, как она управляет внешним трафиком. 12 ноября 2025 года Kubernetes объявила о прекращении использования Ingress Nginx, одного из наиболее широко используемых компонентов в собственной облачной инфраструктуре. Максимальное техническое обслуживание продолжится до марта 2026 года, после чего репозиторий перейдет в статус «только для чтения» без каких-либо дальнейших исправлений безопасности, исправлений ошибок или выпусков функций.
Это знаменует собой критический переломный момент для организаций, использующих кластеры Kubernetes. Традиционный API Ingress, хотя и проверенный в боях и знакомый поколениям инженеров, достиг пределов своей конструкции. Ему не хватает поддержки расширенных шаблонов управления трафиком, вынуждает команды бороться с аннотациями, специфичными для конкретного поставщика, и он не может выражать сложные правила маршрутизации, необходимые для современных приложений.
Kubernetes Gateway API является преемником и представляет собой стандартизированную расширяемую структуру, устраняющую эти фундаментальные ограничения. Вместо того, чтобы полагаться на фрагментированные реализации и собственные аннотации, Gateway API представляет унифицированную модель, которая поддерживает многопротокольную маршрутизацию (L4 и L7), детальное управление трафиком, сопоставление шаблонов на основе заголовков, зеркалирование запросов и собственные метрики трафика.
Gateway API, который станет общедоступным в 2023 году, представляет собой ответ сообщества Kubernetes на проблему входящего доступа. Подробное сравнение контроллера Ingress и шлюза можно найти в моей предыдущей статье, опубликованной в The New Stack.
Одной из первых реализаций Gateway API является Nginx Gateway Fabric, которая представляет собой совместимую реализацию API Kubernetes Gateway с открытым исходным кодом, которая использует Nginx в качестве высокопроизводительной плоскости данных. Он разделяет проблемы плоскости управления и плоскости данных, динамически предоставляя экземпляры Nginx для каждого ресурса шлюза и одновременно преобразуя ресурсы API шлюза в конфигурации Nginx. В отличие от традиционных контроллеров Ingress, Nginx Gateway Fabric предоставляет расширенные возможности «из коробки», включая сине-зеленое и канареечное развертывание, A/B-тестирование, манипулирование запросами/ответами и мультитенантное управление на основе ролей.
Это руководство поможет вам реализовать API шлюза на основе Nginx Gateway Fabric, помогая подготовить вашу инфраструктуру к эпохе пост-Ingress. Мы начнем со знакомого развертывания Kubernetes с двумя сервисами: один для Интернета и один для API. Мы будем использовать API шлюза для маршрутизации HTTP-трафика к этим двум внутренним службам ClusterIP.
В этом уроке я использую кластер K3s, работающий внутри виртуальной машины Multipass. Но вы можете использовать любую среду Kubernetes для выполнения шагов, описанных в этом руководстве.
Шаг 1. Определите и разверните пример приложения
Мы определим два развертывания и службы, чтобы предоставить конечные точки Интернета и API как службы ClusterIP в демонстрационном пространстве имен.
Примените YAML и проверьте, запущены ли модули и службы.
kubectl get pods,svc -n demo 1 kubectl get pods,svc -n demo
Наша цель — направить трафик к конечным точкам demo-API и demo-app через Gateway API.
Шаг 2. Развертывание структуры шлюза Nginx
Сначала мы установим CRD, необходимые шлюзу.
kubectl kustomize » \ | kubectl apply -f — 12 kubectl kustomize » \ | kubectl применить -f —
kubectl получить crd | grep шлюз.networking.k8s.io 1 kubectl get crd | grep шлюз.networking.k8s.io
Затем мы развернем Nginx Gateway Fabric через диаграмму Helm.
helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \ —create-namespace \ -n nginx-gateway \ —set nginx.service.type=NodePort 1234 helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \ —create-namespace \ -n nginx-gateway \ —set nginx.service.type=Порт узла
Обратите внимание, что мы указываем тип службы как NodePort. Если вы используете управляемую среду Kubernetes, измените это значение на LoadBalancer.
Проверьте установку, проверив nginx-шлюз.
kubectl get pods,svc -n nginx-gateway 1 kubectl get pods,svc -n nginx-gateway
Следующим шагом является развертывание шлюза, который разработчики приложений будут использовать для определения маршрута к своим службам, работающим в их пространствах имен.
Примените файл YAML и убедитесь, что шлюз создан правильно.
kubectl apply -f шлюз.yaml 1 kubectl apply -f шлюз.yaml
kubectl get pods,svc -n nginx-gateway 1 kubectl get pods,svc -n nginx-gateway
Мы видим, что шлюз создан и доступен через NodePort 31678.
Шаг 3. Определите маршрут к примеру приложения
Когда шлюз готов, пришло время создать маршрут. Обычно это делают разработчики, развертывающие свое приложение в Kubernetes. Маршрут работает в том же пространстве имен, что и приложение.
Определите маршрут и разверните его.
kubectl apply -froute.yaml 1 kubectl apply -froute.yaml
Это создало HTTPRoute для конечных точек, предоставляемых примером приложения.
Шаг 4. Доступ к конечным точкам HTTP, предоставляемым шлюзом
Мы готовы протестировать маршруты, определенные шлюзом.
Учитывая, что IP-адрес моей виртуальной машины — 192.168.2.5, а NodePort — 31678, я могу сделать запрос cURL для проверки конечных точек.
Мы успешно внедрили API шлюза, чтобы предоставить внутренние конечные точки внешним пользователям. В следующих руководствах я расскажу, как реализовать маршрутизацию на основе TLS. Следите за обновлениями!
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джанакирам MSV — главный аналитик Janakiram & Associates и внештатный преподаватель Международного института информационных технологий. Он также является сертифицированным облачным разработчиком Google, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon,… Читать далее от Джанакирама MSV
