Migracja z Ingress do Gateway API w Kubernetes: praktyczny przewodnik bez marketingu

Wstęp

Ingress w Kubernetes nadal działa i nie jest planowany do usunięcia. Nie oznacza to jednak, że jest to API, które będzie dalej intensywnie rozwijane. Oficjalna dokumentacja Kubernetes wskazuje, że Ingress API jest stabilne, ale zamrożone. Nowe funkcje związane z ruchem sieciowym L4/L7 są rozwijane przede wszystkim w ramach Gateway API.

Gateway API jest projektem Kubernetes SIG Network i można traktować go jako nowocześniejszy model zarządzania ruchem przychodzącym do klastra. Rozwiązuje wiele problemów, które przez lata narosły wokół klasycznego Ingressa: zależność od adnotacji, ograniczony model routingu, słabą separację odpowiedzialności oraz problemy z przenośnością konfiguracji między kontrolerami.

Ten wpis pokazuje, czym Gateway API różni się od Ingress, jak wygląda praktyczna migracja i na co trzeba uważać przed wdrożeniem tego w środowisku produkcyjnym.

1. Ingress nie umarł, ale jest zamrożony

Warto zacząć od ważnego sprostowania:

Ingress nie jest deprecated, ale jego API jest zamrożone. Nowe możliwości routingu i load balancingu w Kubernetes są rozwijane w Gateway API.

To rozróżnienie jest istotne, ponieważ często mylone są trzy różne rzeczy:

Ingress API jako zasób Kubernetes.
Konkretny kontroler Ingress, np. ingress-nginx, Traefik, HAProxy, Kong.
Gateway API jako nowszy model zarządzania ruchem.

Ingress nadal może być używany, ale jeżeli budujemy nową platformę Kubernetes albo chcemy uporządkować routing w większym środowisku, Gateway API jest obecnie znacznie lepszym kierunkiem.

2. Problem z klasycznym Ingress

Typowy obiekt Ingress wygląda prosto:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: demo
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Na pierwszy rzut oka wszystko wygląda poprawnie:

mamy host app.example.com,
mamy ścieżkę /api,
mamy backend api-service,
mamy TLS,
mamy przekierowanie HTTP → HTTPS.

Problem zaczyna się przy bardziej zaawansowanej konfiguracji. Wiele funkcji nie jest częścią samego API Ingress, tylko jest obsługiwane przez adnotacje konkretnego kontrolera.

Przykład:

nginx.ingress.kubernetes.io/rewrite-target: /

To nie jest uniwersalna funkcja Kubernetes. To jest funkcja specyficzna dla kontrolera ingress-nginx.

Jeżeli kiedyś będziemy chcieli przejść z ingress-nginx na inny kontroler, np. Traefik, HAProxy, Kong albo Istio, część tych adnotacji może przestać działać albo wymagać przepisania.

W praktyce oznacza to, że konfiguracja Ingress często jest mniej przenośna, niż wygląda.

3. Czym jest Gateway API

Gateway API wprowadza bardziej strukturalny model zarządzania ruchem. Zamiast jednego obiektu Ingress, mamy kilka wyspecjalizowanych zasobów.

Najważniejsze z nich to:

GatewayClass
Gateway
HTTPRoute
GRPCRoute
TLSRoute
ReferenceGrant

W najprostszym przypadku interesują nas głównie trzy pierwsze.

4. GatewayClass

GatewayClass określa, jaki kontroler Gateway API będzie obsługiwał dany typ Gateway.

Można to porównać do IngressClass, ale w modelu Gateway API.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: public-gateway-class
spec:
  controllerName: example.com/gateway-controller

W realnym środowisku controllerName musi pochodzić z dokumentacji konkretnego kontrolera.

Przykładowe implementacje Gateway API:

Cilium Gateway API
Istio
Envoy Gateway
NGINX Gateway Fabric
Kong
Traefik
HAProxy
GKE Gateway Controller
AWS Load Balancer Controller z obsługą Gateway API

Samo Gateway API jest specyfikacją. Do działania potrzebny jest kontroler, który tę specyfikację implementuje.

5. Gateway

Gateway definiuje punkt wejścia do klastra.

To tutaj określamy między innymi:

port,
protokół,
hostname,
TLS,
dozwolone namespace’y dla tras.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: gateway-system
spec:
  gatewayClassName: public-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: app.example.com
      allowedRoutes:
        namespaces:
          from: All

    - name: https
      protocol: HTTPS
      port: 443
      hostname: app.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: app-tls
      allowedRoutes:
        namespaces:
          from: All

W tym przykładzie Gateway obsługuje dwa listenery:

HTTP na porcie 80,
HTTPS na porcie 443.

TLS termination jest skonfigurowane na listenerze HTTPS.

6. HTTPRoute

HTTPRoute definiuje routing aplikacyjny.

To tutaj określamy:

host,
ścieżkę,
backend,
wagę ruchu,
redirecty,
modyfikacje nagłówków,
dopasowanie po metodzie HTTP,
dopasowanie po headerach,
dopasowanie po query parametrach.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: demo
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 80

Ten obiekt mówi:

podepnij trasę do Gateway o nazwie public-gateway,
obsługuj host app.example.com,
dla ścieżki /api kieruj ruch do api-service:80.

7. Ingress vs Gateway API

Obszar	Ingress	Gateway API
Punkt wejścia	Zwykle ukryty w kontrolerze	Jawny obiekt `Gateway`
Routing HTTP	`Ingress.rules`	`HTTPRoute`
TLS	`spec.tls` w Ingress	TLS na listenerze Gateway
Kontroler	`IngressClass`	`GatewayClass`
Rozszerzenia	Głównie adnotacje	Pola API, filtry, policies, extension refs
Multi-team	Słaby model separacji	Lepsza separacja platform/app team
Przenośność	Często zależna od kontrolera	Lepsza, ale nadal zależna od implementacji
Canary / traffic split	Zwykle przez adnotacje	Natywnie przez `backendRefs.weight`
Redirecty	Często przez adnotacje	Przez filtr `RequestRedirect`

Gateway API nie usuwa całkowicie zależności od implementacji, ale przenosi więcej funkcji do jawnego, strukturalnego API.

8. Migracja prostego Ingress do HTTPRoute

Załóżmy, że mamy taki Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: demo
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Odpowiednik w Gateway API może wyglądać tak:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: demo
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 80

Mapowanie jest dość czytelne:

Ingress	Gateway API
`spec.rules[].host`	`HTTPRoute.spec.hostnames[]`
`spec.rules[].http.paths[].path`	`HTTPRoute.spec.rules[].matches[].path.value`
`pathType: Prefix`	`type: PathPrefix`
`backend.service.name`	`backendRefs[].name`
`backend.service.port.number`	`backendRefs[].port`
`ingressClassName`	`GatewayClass` / `Gateway`

9. Redirect HTTP → HTTPS

W klasycznym Ingress przekierowanie HTTP na HTTPS często było robione adnotacją:

nginx.ingress.kubernetes.io/ssl-redirect: "true"

W Gateway API można użyć filtra RequestRedirect.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: redirect-http-to-https
  namespace: demo
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
      sectionName: http
  hostnames:
    - app.example.com
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301

To jest dobry przykład przewagi Gateway API. Funkcja, która wcześniej często była adnotacją specyficzną dla kontrolera, staje się częścią jawnego API.

10. Traffic splitting / canary deployment

W Ingress canary deployment często wymagał adnotacji zależnych od kontrolera.

W Gateway API można to zrobić przez backendRefs z wagami.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-canary
  namespace: demo
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-v1
          port: 80
          weight: 90
        - name: api-v2
          port: 80
          weight: 10

W tym przykładzie:

90% ruchu trafia do api-v1,
10% ruchu trafia do api-v2.

To pozwala zrealizować prosty canary bez pisania adnotacji specyficznych dla kontrolera.

11. Separacja odpowiedzialności

Jedną z największych zalet Gateway API jest lepsze rozdzielenie odpowiedzialności.

Przykładowy model:

platform-team:
  - tworzy GatewayClass
  - tworzy Gateway
  - kontroluje listenery
  - kontroluje TLS
  - kontroluje allowedRoutes

app-team:
  - tworzy HTTPRoute
  - wskazuje Service
  - zarządza routingiem aplikacji

W klasycznym Ingress zespół aplikacyjny często definiował wszystko w jednym obiekcie:

host,
TLS,
routing,
adnotacje,
zachowanie kontrolera.

W Gateway API można to rozdzielić. Zespół platformowy udostępnia kontrolowany punkt wejścia, a zespoły aplikacyjne podpinają do niego swoje trasy.

12. Cross-namespace routing i ReferenceGrant

Gateway API umożliwia pracę między namespace’ami, ale robi to w sposób kontrolowany.

Przykładowo:

Gateway może znajdować się w namespace gateway-system,
HTTPRoute może znajdować się w namespace demo,
Service może znajdować się jeszcze gdzie indziej.

W takich przypadkach trzeba zwracać uwagę na uprawnienia i referencje między namespace’ami.

Do kontrolowania referencji między namespace’ami służy między innymi ReferenceGrant.

Jeżeli referencja nie jest dozwolona, zasób może mieć status podobny do:

ResolvedRefs=False
Reason=RefNotPermitted

To jest istotne przy większych klastrach, gdzie zespoły aplikacyjne pracują w osobnych namespace’ach.

13. Praktyczny plan migracji

Migracji nie należy zaczynać od przepisywania YAML-i. Najpierw trzeba zinwentaryzować obecne użycie Ingress.

Krok 1: lista wszystkich Ingressów

kubectl get ingress -A

Eksport do pliku:

kubectl get ingress -A -o yaml > all-ingress.yaml

Krok 2: lista IngressClass

kubectl get ingressclass -A -o yaml > ingressclass-backup.yaml

Krok 3: lista serwisów

kubectl get svc -A -o wide > services.txt

Krok 4: lista certyfikatów TLS

kubectl get secrets -A --field-selector type=kubernetes.io/tls

Krok 5: analiza adnotacji

kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" / "}{.metadata.name}{"\n"}{.metadata.annotations}{"\n\n"}{end}'

Najważniejsze rzeczy do sprawdzenia:

hosty,
ścieżki,
TLS secrets,
ingressClassName,
adnotacje kontrolera,
default backend,
rewrite rules,
redirect HTTP → HTTPS,
timeouts,
rate limits,
authentication,
CORS,
whitelisty IP,
custom snippets.

14. Tabela mapowania

Przed migracją warto przygotować prostą tabelę.

Ingress	Host	Path	Service	TLS Secret	Annotation	Gateway API odpowiednik
`demo/app`	`app.example.com`	`/api`	`api-service:80`	`app-tls`	`ssl-redirect`	`HTTPRoute` + `RequestRedirect`
`demo/app`	`app.example.com`	`/`	`frontend:80`	`app-tls`	`rewrite-target`	zależne od kontrolera / filter
`demo/admin`	`admin.example.com`	`/`	`admin:80`	`admin-tls`	`whitelist-source-range`	policy / controller-specific

Największym problemem zwykle nie są hosty i ścieżki. Największym problemem są adnotacje.

15. Instalacja CRD Gateway API

W wielu dystrybucjach CRD Gateway API są instalowane razem z kontrolerem. Warto jednak sprawdzić, czy API jest dostępne w klastrze.

kubectl api-resources | grep gateway

Przykładowy wynik:

gatewayclasses
gateways
httproutes
referencegrants
grpcroutes
tlsroutes

Jeżeli tych zasobów nie ma, trzeba zainstalować CRD Gateway API albo zainstalować kontroler, który je dostarcza.

16. Wybór kontrolera Gateway API

To jest jedna z najważniejszych decyzji.

Gateway API jest specyfikacją. Kontroler jest implementacją.

Przed migracją trzeba sprawdzić:

Czy kontroler wspiera:
- HTTPRoute?
- TLS termination?
- RequestRedirect?
- RequestHeaderModifier?
- ResponseHeaderModifier?
- traffic splitting?
- cross-namespace routes?
- ReferenceGrant?
- cert-manager integration?
- ExternalDNS integration?
- wymagane polityki bezpieczeństwa?
- wymagane timeouty?
- wymagane mechanizmy rate limit?
- wymagane mechanizmy authentication?

Nie należy zakładać, że każda implementacja Gateway API obsługuje wszystko tak samo.

17. Migracja równoległa zamiast big bang

Najbezpieczniejszy model migracji to uruchomienie Gateway API równolegle z obecnym Ingressem.

Przykładowy plan:

Zostaw obecny Ingress jako produkcyjny.
Wdróż kontroler Gateway API.
Utwórz GatewayClass.
Utwórz Gateway.
Przepisz wybrany Ingress na HTTPRoute.
Użyj osobnego hosta testowego, np. app-gw.example.com.
Przetestuj routing, TLS, redirecty i nagłówki.
Dopiero potem przełącz ruch produkcyjny.
Migruj per aplikacja albo per hostname, nie cały klaster naraz.

18. Testy po migracji

Podstawowe sprawdzenie zasobów:

kubectl get gateway -A
kubectl get httproute -A
kubectl describe gateway -n gateway-system public-gateway
kubectl describe httproute -n demo app-route

Test HTTP:

curl -I http://app.example.com/api

Test HTTPS:

curl -I https://app.example.com/api

Debug TLS:

curl -vk https://app.example.com/api

Test z wymuszonym nagłówkiem Host:

curl -H "Host: app.example.com" http://LOAD_BALANCER_IP/api

Test redirectu:

curl -I http://app.example.com

Oczekiwany wynik przy redirect HTTP → HTTPS:

HTTP/1.1 301 Moved Permanently
Location: https://app.example.com/

19. Cutover produkcyjny

Sposób przełączenia ruchu zależy od środowiska.

Najczęstsze opcje:

Zmiana rekordu DNS na nowy Load Balancer.
Zmiana konfiguracji obecnego Load Balancera.
Stopniowe przenoszenie hostów.
Przenoszenie aplikacji per namespace.
Przenoszenie ruchu przez traffic splitting.

Najbezpieczniej migrować po jednym hostname albo po jednej aplikacji.

Nie należy usuwać starego Ingressa od razu po pierwszym udanym teście. Lepiej zostawić możliwość szybkiego rollbacku.

20. Rollback

Plan rollbacku powinien istnieć przed migracją.

Minimum:

kubectl get ingress -A -o yaml > ingress-backup.yaml

Jeżeli po przełączeniu ruchu pojawi się problem, można:

przywrócić stary rekord DNS,
przywrócić poprzednią konfigurację LB,
usunąć lub odłączyć HTTPRoute,
przywrócić Ingress z backupu,
zmienić wagę ruchu z powrotem na stary backend.

Przykład usunięcia trasy Gateway API:

kubectl delete httproute app-route -n demo

21. Pułapki migracji

21.1. Adnotacje nie zawsze mają odpowiednik

Największy problem migracji to adnotacje.

Przykłady:

nginx.ingress.kubernetes.io/proxy-read-timeout
nginx.ingress.kubernetes.io/proxy-send-timeout
nginx.ingress.kubernetes.io/auth-url
nginx.ingress.kubernetes.io/whitelist-source-range
nginx.ingress.kubernetes.io/configuration-snippet
nginx.ingress.kubernetes.io/server-snippet

Część z nich może mieć odpowiednik w Gateway API, ale część może wymagać rozszerzeń konkretnego kontrolera.

Szczególnie trzeba uważać na:

authentication,
authorization,
rate limiting,
IP allowlist,
custom headers,
custom NGINX snippets,
timeouty,
CORS,
mTLS,
backend TLS,
WebSocket,
gRPC.

21.2. Gateway API nie oznacza automatycznej przenośności

Gateway API poprawia przenośność, ale nie gwarantuje, że każda konfiguracja będzie działać identycznie na każdym kontrolerze.

Trzeba sprawdzić:

status implementacji,
conformance profile,
dokumentację kontrolera,
obsługiwane filtry,
obsługiwane policies,
ograniczenia produkcyjne.

21.3. TLS i namespace’y

Jeżeli Gateway znajduje się w namespace gateway-system, a secret TLS znajduje się w namespace aplikacyjnym, może być potrzebna dodatkowa konfiguracja.

Warto przyjąć jasny model:

Opcja 1:
  Gateway i TLS Secret w tym samym namespace.

Opcja 2:
  TLS zarządzany centralnie przez platform-team.

Opcja 3:
  Cross-namespace references kontrolowane przez ReferenceGrant.

Bez jasnego modelu TLS migracja może szybko stać się chaotyczna.

21.4. RBAC

Gateway API daje lepszy model separacji, ale wymaga dobrze ustawionego RBAC.

Przykład:

platform-team:
  - może zarządzać GatewayClass
  - może zarządzać Gateway
  - może zarządzać TLS
  - może kontrolować allowedRoutes

app-team:
  - może zarządzać HTTPRoute w swoim namespace
  - nie może zmieniać Gateway
  - nie może przejmować cudzych hostname’ów

To jest szczególnie ważne w klastrach współdzielonych przez wiele zespołów.

22. ingress2gateway

Do migracji można wykorzystać narzędzie ingress2gateway.

Nie należy jednak traktować go jako magicznego automatu, który rozwiąże wszystkie problemy.

Przykładowy workflow:

kubectl get ingress -A -o yaml > ingress.yaml

Konwersja:

ingress2gateway print \
  --input-file ingress.yaml \
  --providers ingress-nginx \
  > gateway-api.yaml

Weryfikacja:

kubectl diff -f gateway-api.yaml

Dry run:

kubectl apply --dry-run=server -f gateway-api.yaml

ingress2gateway może oszczędzić czas, ale nadal trzeba ręcznie sprawdzić:

adnotacje,
redirecty,
TLS,
rewrite rules,
zachowanie kontrolera,
zgodność z wymaganiami aplikacji.

Najlepiej traktować to narzędzie jako generator pierwszej wersji manifestów, a nie jako finalną migrację produkcyjną.

23. Minimalny checklist migracyjny

[ ] Mam listę wszystkich Ingressów.
[ ] Mam backup obecnych Ingressów.
[ ] Mam listę wszystkich IngressClass.
[ ] Mam listę wszystkich hostów.
[ ] Mam listę wszystkich ścieżek.
[ ] Mam listę wszystkich TLS Secret.
[ ] Mam listę wszystkich adnotacji.
[ ] Wiem, który kontroler Gateway API wybieram.
[ ] Sprawdziłem dokumentację kontrolera.
[ ] Sprawdziłem conformance implementacji.
[ ] Mam zainstalowane CRD Gateway API.
[ ] Mam GatewayClass.
[ ] Mam Gateway z listenerami HTTP/HTTPS.
[ ] Przepisałem Ingress na HTTPRoute.
[ ] Przepisałem redirecty.
[ ] Przepisałem konfigurację TLS.
[ ] Sprawdziłem rewrite rules.
[ ] Sprawdziłem timeouty.
[ ] Sprawdziłem rate limit.
[ ] Sprawdziłem authentication.
[ ] Sprawdziłem CORS.
[ ] Sprawdziłem IP allowlist.
[ ] Przetestowałem konfigurację na osobnym hostname.
[ ] Mam plan rollbacku.
[ ] Dopiero teraz przełączam ruch produkcyjny.

24. Przykładowa ścieżka migracji dla jednej aplikacji

Załóżmy, że aplikacja działa obecnie tak:

Host:
  app.example.com

Path:
  /api

Backend:
  api-service:80

TLS:
  app-tls

Ingress controller:
  ingress-nginx

Plan migracji:

Eksport starego Ingress:

kubectl get ingress app-ingress -n demo -o yaml > app-ingress-backup.yaml

Utworzenie testowego hosta:

app-gw.example.com

Utworzenie HTTPRoute dla testowego hosta:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route-test
  namespace: demo
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
  hostnames:
    - app-gw.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 80

Test:

curl -vk https://app-gw.example.com/api

Po pozytywnych testach zmiana hosta na produkcyjny:

hostnames:
  - app.example.com

Przełączenie DNS albo LB.
Obserwacja logów, metryk i błędów 4xx/5xx.
Usunięcie starego Ingress dopiero po stabilizacji.

25. Kiedy warto migrować

Migracja do Gateway API ma sens, jeżeli:

budujesz nową platformę Kubernetes,
masz wiele zespołów w jednym klastrze,
masz dużo adnotacji w Ingressach,
chcesz ustandaryzować routing,
chcesz lepiej rozdzielić odpowiedzialności,
chcesz mieć lepszy model canary/traffic splitting,
używasz service mesh albo planujesz go używać,
obecny Ingress controller zaczyna być ograniczeniem.

26. Kiedy nie warto migrować od razu

Migracja może nie mieć sensu natychmiast, jeżeli:

masz kilka prostych Ingressów,
nie używasz zaawansowanych adnotacji,
obecny kontroler działa stabilnie,
nie masz czasu na testy,
nie masz jeszcze wybranego kontrolera Gateway API,
nie masz planu rollbacku,
zespół nie zna jeszcze Gateway API.

Gateway API jest dobrym kierunkiem, ale migracja nie powinna być robiona tylko dlatego, że jest to nowsze API.

27. Podsumowanie

Ingress w Kubernetes nadal działa, ale jego API jest zamrożone. Jeżeli środowisko jest proste, nie ma potrzeby natychmiastowej migracji. Jeżeli jednak zarządzamy większym klastrem, wieloma aplikacjami, wieloma zespołami albo skomplikowanymi adnotacjami, Gateway API daje znacznie lepszy model.

Największe zalety Gateway API to:

jawny punkt wejścia przez Gateway,
separacja odpowiedzialności między platform-team i app-team,
mniej logiki ukrytej w adnotacjach,
lepszy model routingu,
natywne traffic splitting,
bardziej strukturalna konfiguracja,
lepsze dopasowanie do środowisk multi-team i platform engineering.

Migrację należy jednak traktować jak projekt sieciowy, nie jak prostą zamianę:

kind: Ingress

na:

kind: HTTPRoute

Najbezpieczniejsza strategia to:

zinwentaryzować obecne Ingressy,
przeanalizować adnotacje,
wybrać kontroler Gateway API,
przetestować migrację równolegle,
przełączać ruch stopniowo,
mieć gotowy rollback.

Gateway API nie jest magicznym rozwiązaniem wszystkich problemów, ale jest obecnie najbardziej sensownym kierunkiem rozwoju routingu w Kubernetes.

Źródła

Kubernetes Documentation — Ingress
https://kubernetes.io/docs/concepts/services-networking/ingress/
Kubernetes Documentation — Gateway API
https://kubernetes.io/docs/concepts/services-networking/gateway/
Gateway API Documentation — Migrating from Ingress
https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress/
Gateway API Documentation — Implementations
https://gateway-api.sigs.k8s.io/implementations/
Gateway API Documentation — Conformance
https://gateway-api.sigs.k8s.io/docs/concepts/conformance/
Gateway API API Specification
https://gateway-api.sigs.k8s.io/reference/api-spec/
ingress2gateway — Kubernetes SIGs
https://github.com/kubernetes-sigs/ingress2gateway
Gateway API GitHub Repository
https://github.com/kubernetes-sigs/gateway-api