Możnaby powiedzieć, że Kubernetes Gateway API to następca klasycznego Ingress, który jest bardziej nowoczesnym, rozszerzalnym standardem routingu ruchu w klastrach Kubernetes, rozwijanym przez SIG Network. W repozytorium k8s-gateway-api zebrałem praktyczne przykłady działania dwóch podejść do obsługi ruchu przychodzącego:

  • klasycznego NGINX Ingress,
  • Gateway API na przykładzie:
    • KinD
    • Istio
architecture-beta group nginx_group(logos:nginx)[Ingress NGINX] group kind_group(logos:kubernetes)[KinD Gateway API] group istio_group(simple-icons:istio)[Istio Gateway API] service nginx_ctrl(logos:nginx)["ingress-nginx-controller"] in nginx_group service nginx_ingress(logos:kubernetes)[Ingress] in nginx_group service nginx_svc(logos:kubernetes)[Service] in nginx_group service podinfo(logos:kubernetes)[Pod] in nginx_group service kind_envoy(logos:envoyproxy)[Envoy proxy] in kind_group service kind_gateway(logos:kubernetes)[Gateway] in kind_group service kind_httproute(logos:kubernetes)[HTTPRoute] in kind_group service kind_svc(logos:kubernetes)[Service] in kind_group service echo_kind(logos:kubernetes)[Pod] in kind_group service istio_gw(simple-icons:istio)[Istio Envoy gateway] in istio_group service istio_gateway(logos:kubernetes)[Gateway] in istio_group service istio_httproute(logos:kubernetes)[HTTPRoute] in istio_group service istio_svc(logos:kubernetes)[Service] in istio_group service echo_istio(logos:kubernetes)[Pod] in istio_group nginx_ctrl:R --> L:nginx_ingress nginx_ingress:R --> L:nginx_svc nginx_svc:R --> L:podinfo kind_envoy:R --> L:kind_gateway kind_gateway:R --> L:kind_httproute kind_httproute:R --> L:kind_svc kind_svc:R --> L:echo_kind istio_gw:R --> L:istio_gateway istio_gateway:R --> L:istio_httproute istio_httproute:R --> L:istio_svc istio_svc:R --> L:echo_istio

Dlaczego Gateway API zamiast Ingress? Link to heading

Klasyczny zasób Ingress ma swoje ograniczenia — słabo radzi sobie z bardziej zaawansowanymi regułami routingu, a różne kontrolery implementują go w niekompatybilny sposób przez własne adnotacje. Gateway API rozwiązuje te problemy przez:

  • wyraźny podział ról — GatewayClass definiuje dostawcę infrastruktury, Gateway określa punkt wejścia ruchu, a HTTPRoute (lub TCPRoute itp.) opisuje reguły routingu
  • bogaty model routingu — natywna obsługa podziału ruchu (traffic splitting), przekierowań, modyfikacji nagłówków i dopasowania ścieżek
  • rozszerzalność — każdy dostawca (Istio, Cilium, Envoy Gateway i inni) implementuje ten sam API, co daje przenośność konfiguracji między środowiskami

Dwa (albo i w sumie trzy) podejścia w praktyce Link to heading

Repozytorium demonstruje kompletne, działające przykłady na lokalnym klastrze KIND (Kubernetes in Docker).

NGINX Ingress — klasyczne podejście, nadal powszechne w produkcji. Kontroler wdrażany jest z pełnym zestawem RBAC, webhookiem walidacyjnym i usługą NodePort. Konfiguracja opiera się na zasobie Ingress z adnotacjami specyficznymi dla NGINX.

KinD Gateway API — implementacja standardu Gateway API z wbudowanym cloud kontrolerem KinD. Gateway nasłuchuje na porcie 80 dla domeny *.example.gateway.kind.com, a routing definiują zasoby HTTPRoute. Całość pokazuje, jak Gateway API wygląda bez dodatkowej warstwy service mesh.

Istio Gateway API — najbardziej zaawansowana opcja. Istio wdraża się przez Helm, a gateway obsługuje domenę *.example.gateway.istio.com. Dzięki integracji z service mesh zyskujemy mTLS, observability i zaawansowane mechanizmy zarządzania ruchem bez modyfikowania samej aplikacji.

Automatyzacja przez Taskfile Link to heading

Całość zarządzana jest przez taskfile.yml, który automatyzuje:

  • tworzenie i usuwanie klastra KinD wraz z konfiguracją mapowania portów
  • instalację kontrolerów (NGINX, KinD Gateway, Istio przez Helm)
  • wdrożenie aplikacji demonstracyjnych (podinfo z autoskalowaniem i metrykami, echo)
  • konfigurację port-forwardingu i proxy do testowania ruchu

Dzięki temu cały eksperyment — od pustego środowiska do działającego Gateway API — zamyka się w kilku komendach.

Podsumowanie Link to heading

Gateway API to kierunek, w którym zmierza ekosystem Kubernetes. Niezależnie od tego, czy korzystasz z Istio, Cilium, czy innego dostawcy, interfejs pozostaje ten sam. Repozytorium k8s-gateway-api może służyć do nauki tego standardu bez potrzeby dostępu do chmury.