Хостинг
CMS и платформы
Безопасность и производительность
Интересное:
Инфраструктура, VPS и облачный хостинг

Зачем переходить с Ingress на Gateway API? Будущее сетевого доступа в OVHcloud Managed Kubernetes

  • Автор: Pro-IT
  • Вчера, 19:34
  • 0
  • 0
Поделиться:
Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?

В течение многих лет API Ingress в Kubernetes и популярный контроллер Ingress NGINX (ingress-nginx) были стандартным способом предоставления доступа к приложениям, работающим внутри кластера Kubernetes.

Но экосистема меняется: группа SIG network в Kubernetes объявила о прекращении поддержки Ingress NGINX в марте 2026 года.

После марта 2026 года Ingress NGINX больше не будет получать новые функции, выпуски, патчи безопасности и исправления ошибок.

Более того, проект Kubernetes рекомендует использовать Gateway вместо Ingress.

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

Хотя OVHcloud Managed Kubernetes Service (MKS) пока не предоставляет нативный GatewayClass, вы уже сегодня можете воспользоваться возможностями Gateway API, развернув собственный контроллер 💪.

Кроме того, до тех пор пока Gateway API не станет полностью интегрирован с провайдерами OpenStack, существует промежуточный вариант: использование современного, активно поддерживаемого контроллера Ingress, отличного от ingress-nginx.

Ограничения текущей модели контроллера Ingress

Традиционная модель Ingress в Kubernetes изначально была простой: определить ресурс Ingress, установить Ingress Controller и позволить ему настроить единый прокси-сервер (обычно Nginx) для маршрутизации трафика.

Такая конструкция работает, но имеет ограничения:

– Единая монолитная «точка входа»: Весь HTTP-трафик для всего кластера проходит через один общий прокси-сервер. Это добавляет сложности, конфликтов конфигурации и проблем с масштабированием.
– Ограничения по протоколам: только HTTP и HTTPS. Поддержка gRPC, HTTP/2, TCP, UDP или TLS passthrough реализована не везде и зависит от конкретного контроллера.
– Сильная зависимость от аннотаций: Для расширенных функций (таймауты, перезаписи, обработка заголовков…) требуются пользовательские аннотации.
– Поддержка сильно зависит от сторонних поставщиков и облачных балансировщиков нагрузки: Каждый контроллер Ingress (сторонние провайдеры) использует свои собственные специализированные аннотации.

Наконец, как уже упоминалось, самый популярный контроллер Ingress, Ingress NGINX, будет снят с поддержки в марте 2026 года.

Переходное решение: использование современного контроллера Ingress (Traefik, Contour, HAProxy…)

Прежде чем переходить на Gateway API, в качестве промежуточного решения пользователи OVHcloud MKS могут просто заменить Ingress Nginx на современный, активно поддерживаемый контроллер Ingress.

Это позволяет:

– продолжать использовать существующие манифесты Ingress
– сохранить ту же архитектуру: Service типа LoadBalancer → OVHcloud Public Cloud Load Balancer → Ingress Controller
– избежать зависимости от неподдерживаемых или устаревших компонентов
– получить новые возможности (лучшая поддержка gRPC, встроенные дашборды, улучшенное поведение на L7…)

Популярные альтернативы:

Traefik:
– Очень простая установка
– Отличная поддержка HTTP/2, gRPC, WebSockets
– Встроенный дашборд
– Поддерживает как Ingress, так и Gateway API
– Активно поддерживается
– Плавная миграция с NGINX Ingress Controller на Traefik благодаря совместимости аннотаций NGINX

Contour (Envoy):
– Контроллер Ingress на основе Envoy
– Отличная производительность
– Хороший шаг на пути к Gateway API

HAProxy Ingress:
– Чрезвычайно производительный
– Маршрутизация уровня L7 корпоративного класса
– Опциональная поддержка Gateway API

NGINX Gateway Fabric (NGF):
– Преемник Ingress NGINX
– Построен непосредственно вокруг Gateway API
– Ещё находится в стадии развития, но является сильным кандидатом на долгосрочную перспективу

Если вам интересно, вы можете ознакомиться с более полным списком контроллеров Ingress.

Установка альтернативного контроллера Ingress на OVHcloud MKS

Мы покажем вам, как установить Traefik в качестве альтернативного контроллера Ingress и использовать его для создания одного OVHcloud Public Cloud Load Balancer (на основе OpenStack Octavia).

Установка Traefik:

helm repo add traefik https://traefik.github.io/charts
helm repo update

helm install traefik traefik/traefik --namespace traefik --create-namespace --set service.type=LoadBalancer

Это автоматически запускает:
– OpenStack CCM (используемый OVHcloud)
– создание OVHcloud Public Cloud Load Balancer
– предоставление доступа к Traefik через публичный IP-адрес

Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?

Через несколько секунд балансировщик нагрузки станет активным.

Проверьте, что Traefik работает:

$ kubectl get all -n traefik
NAME                           READY   STATUS    RESTARTS   AGE
pod/traefik-6777c5db85-pddd6   1/1     Running   0          31s

NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/traefik   LoadBalancer   10.3.129.188   <pending>     80:30267/TCP,443:30417/TCP   31s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/traefik   1/1     1            1           31s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/traefik-6777c5db85   1         1         1       31s

Чтобы использовать его, создайте файл ingress.yaml со следующим содержимым:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "traefik"  # Указывает Traefik в качестве контроллера ingress
spec:
  rules:
    - host: my-app.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

И примените его в своем кластере:

kubectl apply -f ingress.yaml

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

Gateway API: Современная, гибкая модель сетевого взаимодействия

Gateway API — это сетевой API Kubernetes следующего поколения. Он вводит более четкие роли и более гибкие архитектуры.

Gateway API разделяет обязанности между:
– GatewayClass: определяет тип шлюза и контроллер, который им управляет
– Gateway: фактическая точка входа (например, балансировщик нагрузки)
– Routes: правила маршрутизации, специфичные для протокола (HTTPRoute, TLSRoute, GRPCRoute, TCPRoute…)

Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?

Gateway API поддерживает:
– HTTP(S)
– HTTP/2
– gRPC
– TCP
– TLS passthrough
…последовательно и переносимым образом.

В отличие от Ingress, Gateway API явно разработан для того, чтобы позволить таким провайдерам, как OVHcloud, AWS, GCP, Azure:
– подготавливать балансировщики нагрузки (LB)
– управлять слушателями (listeners)
– открывать несколько портов
– интегрироваться с функциями их балансировщиков нагрузки
Это прокладывает путь к нативной поддержке GatewayClass от OVHcloud.

Как это работает сегодня в OVHcloud MKS?

OVHcloud MKS полагается на OpenStack Cloud Controller Manager (CCM) для подготовки Public Cloud балансировщиков нагрузки OVHcloud в ответ на создание Service типа LoadBalancer.

Поскольку MKS пока не включает нативный GatewayClass, вы можете использовать Gateway API сегодня следующим образом:

1. You deploy an existing Gateway Controller (Envoy Gateway, Traefik, Contour/Envoy…) and its GatewayClass.
2. The controller deploys a Data Plane proxy inside the cluster.
3. To expose that proxy, you still have to create a Service of type LoadBalancer (and your app of course).
4. The CCM provisions an OVHcloud Public Cloud Load Balancer and forwards traffic to your proxy.

Thanks to that, you will have a fully functional Gateway API. The workflow is very similar to that which is required for using NGINX Ingress controller.

Using the Gateway API on OVHcloud MKS today

You can already use the Gateway API by deploying your preferred controller.

Here’s an example using Envoy Gateway, one of the most future-proof options.

Install Gateway API CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

Deploy Envoy Gateway:

helm install eg oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

You should have a result like this:

$ helm install eg oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

Pulled: docker.io/envoyproxy/gateway-helm:1.6.0
Digest: sha256:5c55e7844ae8cff3152ca00330234ef61b1f9fa3d466f50db2c63a279f1cd1df
NAME: eg
LAST DEPLOYED: Mon Dec  1 16:27:07 2025
NAMESPACE: envoy-gateway-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
**************************************************************************
*** PLEASE BE PATIENT: Envoy Gateway may take a few minutes to install ***
**************************************************************************

Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway.

Thank you for installing Envoy Gateway! 🎉

Your release is named: eg. 🎉

Your release is in namespace: envoy-gateway-system. 🎉

To learn more about the release, try:

  $ helm status eg -n envoy-gateway-system
  $ helm get all eg -n envoy-gateway-system

To have a quickstart of Envoy Gateway, please refer to https://gateway.envoyproxy.io/latest/tasks/quickstart.

To get more details, please visit https://gateway.envoyproxy.io and https://github.com/envoyproxy/gateway.

Check the Envoy gateway is running:

$ kubectl get po -n envoy-gateway-system
NAME                            READY   STATUS    RESTARTS   AGE
envoy-gateway-9cbbc577c-5h5qw   1/1     Running   0          16m

As a quickstart, you can install directly the GatewayClass, Gateway, HTTPRoute and an example app:

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/quickstart.yaml -n default

This command deploys a GatewayClass, a Gateway, a HTTPRoute and an app deployed in a deployment and exposed through a service:

gatewayclass.gateway.networking.k8s.io/eg created
gateway.gateway.networking.k8s.io/eg created
serviceaccount/backend created
service/backend created
deployment.apps/backend created
httproute.gateway.networking.k8s.io/backend created

As you can see, a GatewayClass have been deployed:

$ kubectl get gatewayclass -o yaml | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: GatewayClass
  metadata:
    name: eg
  spec:
    controllerName: gateway.envoyproxy.io/gatewayclass-controller
kind: List
metadata:
  resourceVersion: ""

Note that a GatewayClass is a cluster-wide resource so you don’t have to specify any namespace.

A Gateway have been deployed also:

$ kubectl get gateway -o yaml -n default | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: Gateway
  metadata:
    name: eg
    namespace: default
  spec:
    gatewayClassName: eg
    listeners:
    - allowedRoutes:
        namespaces:
          from: Same
      name: http
      port: 80
      protocol: HTTP
kind: List
metadata:
  resourceVersion: ""

A HTTPRoute also:

$ kubectl get httproute -o yaml -n default | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: backend
    namespace: default
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: backend
        port: 3000
        weight: 1
      matches:
      - path:
          type: PathPrefix
          value: /
kind: List
metadata:
  resourceVersion: ""

In order to retrieve the external IP (of the external Load Balancer), you just have to get information about the Gateway and export it in an environment variable:

$ kubectl get gateway eg
NAME   CLASS   ADDRESS        PROGRAMMED   AGE
eg     eg      xx.xxx.xx.xxx   True        18m

$ export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

$ echo $GATEWAY_HOST
xx.xxx.xx.xxx

And finally, a backend service have been deployed with its deployment:

$ kubectl get pod,svc -l app=backend -n default
NAME                           READY   STATUS    RESTARTS   AGE
pod/backend-765694d47f-zr6hh   1/1     Running   0          21m

NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/backend   ClusterIP   10.3.114.179   <none>        3000/TCP   21m

In order to create your own Gateway and *Route resources, don’t hesitate to take a look at the Gateway API website.

Conclusion

Two migration paths are currently available for OVHcloud MKS users:

  • Short-term: switch to a modern Ingress Controller (Traefik, Contour, HAProxy, NGF…). It provides full support for current Ingress usage, without requiring API changes.
  • Long-term: adopt the Gateway API. Gateway API brings multi‑protocol support, clearer separation of roles, and is the strategic direction of Kubernetes networking.

Which approach and which tool should you choose? Well, it’s up to you, depending on your use cases, your teams, your needs… 🙂

As we have seen in this blog post, OVHcloud MKS users can begin adopting these technologies today, safely and incrementally.

Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?
Kubernetes Gateway API Ingress OVHcloud Managed Kubernetes сетевой доступ миграция балансировка нагрузки контроллер

Случайное

img
Сколько стоит ваш домен? Раскрываем
23-10-2025, 20:31
img
5 решений вместо WooCommerce: обзор
19-10-2025, 21:46
img
5 причин выбрать домен .ONLINE для
20-10-2025, 02:31
img
Как узнать, на каком хостинге работает
15-11-2025, 11:35
img
WPX для агентств: высокая
14-11-2025, 15:31