Kubernetes Ingress és Gateway API: forgalom a cluster felé

| Olvasási idő: 6 perc |

Legutóbb a Kubernetes Service-ekről volt szó: megnéztük, hogyan tesz elérhetővé egy alkalmazást a ClusterIP, a NodePort és a LoadBalancer típus. Ha olvastad, biztosan emlékszel, a cikknek a végén jeleztem, hogy az Ingress külön témát érdemel. Most ez következik, és mellé vesszük az utódját, a Gateway API-t is, mert 2026-ban már nem érdemes a kettőt egymástól függetlenül tanulni.

Mi a gond a sok LoadBalancer Service-el?

A LoadBalancer típusú Service egyszerű és gyorsan működik: a cloud provider létrehoz mögé egy valódi terheléselosztót Egyetlen alkalmazásnál ez teljesen rendben van. Tíz alkalmazásnál ez akár tíz külön terheléselosztót is jelenthet, amelyek külön cloud-erőforrásként költséget és üzemeltetési feladatot jelentenek. Ráadásul minden alkalmazás külön külső belépési pontot kaphat.

Az Ingress ezt a helyzetet oldja meg. Ahelyett, hogy minden Service saját belépési pontot kapna, egyetlen közös bejáratot hozunk létre, amely a kérés hostneve vagy útvonala (path) alapján dönti el, melyik Service felé menjen tovább a forgalom. A Service-ek közben maradhatnak egyszerű ClusterIP típusúak.

Egy egyszerű példa: a shop.pelda.hu kérései a webshop Service-hez mennek, az api.pelda.hu kérései az API-hoz, a shop.pelda.hu/admin pedig egy harmadik szolgáltatáshoz. Mindez egyetlen belépési ponton keresztül.

Ingress resource és Ingress controller

Az Ingress két részből áll, és ez a leggyakoribb félreértés forrása.

Az Ingress resource maga a szabálygyűjtemény. Egy YAML-ben leírt API objektum a networking.k8s.io/v1 csoportban, amelyet ugyanúgy kezelünk kubectl-lel, mint egy Deployment-et vagy egy Service-t.

Az Ingress controller az a komponens, amely ezeket a szabályokat végre is hajtja. Egy vezérlő komponens, amely a Kubernetes API-n keresztül figyeli az Ingress erőforrásokat, és azok alapján konfigurálja a forgalom kezelését. A controller megvalósítása környezettől függően futhat a clusterben vagy lehet a cloud provider által felügyelt komponens. A legtöbb controllerrel ellentétben nem része a kube-controller-manager-nek, ezért külön kell telepíteni. Controller nélkül az Ingress objektum létrejön, de semmi nem történik.

A Kubernetes dokumentációjában szereplő minimális példa így néz ki:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Az ingressClassName határozza meg, melyik controller foglalkozzon a szabállyal, mivel egy clusterben több controller is futhat egyszerre. Az annotations rész pedig már átvezet az Ingress korlátaihoz.

Ingress a három nagy felhőben

Managed Kubernetes esetén a controllert gyakran maga a felhőszolgáltató adja:

Platform	Ingress controller	Mit hoz létre a háttérben
AWS (EKS)	AWS Load Balancer Controller	Application Load Balancer
Azure (AKS)	Application Gateway Ingress Controller	Azure Application Gateway
GCP (GKE)	GKE Ingress	Google Cloud Application Load Balancer

Ezek is valódi, fizetős cloud erőforrások. A különbség az, hogy egy közös belépési pont szolgál ki sok Service-t, így sokkal kevesebb terheléselosztót kell létrehozni és nyomon követni.

Azure-on az Application Gateway mellett az újabb Application Gateway for Containers megoldás is támogatja a Kubernetes Ingress és Gateway API erőforrásait. Google Cloud esetén a GKE-n a klasszikus Ingress megoldás továbbra is használható, de a Google a Gateway API használatát is támogatja és fejleszti az újabb forgalomkezelési funkciókhoz.

Hol ér véget az Ingress?

Az Ingress API szándékosan egyszerű: elsősorban HTTP(S) forgalom host- és path-alapú routingjára, valamint TLS kezelésére szolgál. Olyan fejlettebb funkciók, mint például a header alapú routing, a canary jellegű forgalommegosztás vagy a nem HTTP-alapú protokollok támogatása nem egységes részei az Ingress API-nak. Ezeket az egyes controllerek saját extensionökkel, például annotationökkel, ConfigMapekkel vagy CRD-kkel egészíthetik ki. Ez viszont controllerfüggőséget okozhat, és megnehezítheti a későbbi váltást.

Van egy szervezeti korlát is: az Ingress modellje kevésbé támogatja a platform- és alkalmazáscsapat felelősségeinek tiszta szétválasztását. A Gateway API-t ezzel szemben eleve szerepkörök szerinti felosztásra tervezték: a GatewayClass és Gateway tipikusan az infrastruktúra- vagy platformcsapat, míg a Route erőforrások az alkalmazáscsapatok kezelésében lehetnek.

Emiatt az Ingress API funkcionálisan be van fagyasztva: továbbra is támogatott, de új képességek már nem kerülnek bele. A fejlesztés a Gateway API-ban folytatódik.

Mi történt az ingress-nginx-szel?

Az ingress-nginx évekig az egyik legelterjedtebb Ingress controller volt, a legtöbb oktatóanyag ma is ezt mutatja be. A Kubernetes SIG Network és a Security Response Committee 2025 novemberében bejelentette a projekt nyugdíjazását. A karbantartás 2026 márciusáig tartott, azóta nem jelenik meg hozzá új kiadás, hibajavítás és biztonsági javítás sem. A meglévő telepítések tovább működnek, de a Kubernetes kifejezetten azt javasolja, hogy az érintettek tervezzék meg az átállást a Gateway API-ra vagy egy másik Ingress controllerre.

Fontos különbség, hogy ez a közösségi ingress-nginx projektre vonatkozik, nem az F5 által fejlesztett NGINX Ingress Controllerre. Hogy egy clusterben fut-e, azt a hivatalos ajánlás szerint így lehet ellenőrizni:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

A Gateway API három szerepe

A Gateway API a gateway.networking.k8s.io/v1 csoportba tartozik, és a feladatot három stabil objektumra bontja:

Objektum	Mit ír le	Ki kezeli jellemzően
GatewayClass	Melyik controller valósítja meg a gateway-eket	Infrastruktúra csapat
Gateway	A belépési pont példánya: protokollok és portok	Platformcsapat
HTTPRoute	A routing szabályok a Service-ek felé	Fejlesztők

A hivatalos dokumentáció példája jól mutatja ezt a szétválasztást. A Gateway egy HTTP listenert nyit a 80-as porton:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway 
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80

A HTTPRoute pedig ehhez a Gateway -hez kapcsolódva a /login útvonalat egy Service felé irányítja:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.pelda.hu"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

Ami az Ingressben sokszor controller-specifikus extension vagy annotation volt, annak számos megfelelője a Gateway API szabványos része. Ilyen például a header- és path-alapú routing, illetve a súlyozott forgalommegosztás. További funkciók, például a request mirroring, szintén definiálva vannak a Gateway API-ban, de egyes funkciók Extended támogatási szinten vannak. A szabványos core funkciók használatával a konfiguráció hordozhatóbbá válik a különböző Gateway API implementációk között. Az implementation-specific vagy egyes Extended funkciók használata azonban továbbra is okozhat eltéréseket. A namespace-ek közötti hivatkozásokat pedig külön engedélyezni kell, ami biztonságosabbá teszi a több csapat által közösen használt clustereket.

A nagy felhőszolgáltatók is kínálnak Gateway API-alapú megoldásokat. GKE-n elérhető a Google által biztosított Gateway controller, Azure-on az Application Gateway for Containers támogatja a Gateway API-t, AWS-en pedig több megoldás is rendelkezésre áll, például az AWS Gateway API Controller VPC Lattice-t használva vagy az AWS Load Balancer Controller ALB-vel.

Amit nem részleteztem az Ingress esetén sem

Most nem tértünk ki a TLS tanúsítványok kezelésére, a controllerek telepítésének részleteire és az Ingressről Gateway API-ra történő migrációra. A service mesh is kimaradt, pedig például a rate limiting vagy a részletes forgalmi metrikák ott kapnak igazán szerepet. Ezek mind önálló cikket érdemelnek, és talán később sorra is kerülnek. A monitoring és a high availability szintén később lesz fontos, amikor az alapműködés már stabil.

Amire érdemes figyelni

Még az AI korában is könnyű egy régi dokumentációt követve ingress-nginx-szel indítani egy új projektet. Ezért azt javaslom, hogy mielőtt bármit telepítesz, nézd meg, hogy az adott eszköz aktívan karbantartott-e. Új környezetben érdemes egyből a Gateway API-val kezdeni, meglévő Ingress alapú rendszereknél pedig tervezetten, lépésenként átállni.

A költségoldalt se feledd: felhőben az Ingress vagy Gateway mögött gyakran valamilyen felügyelt terheléselosztó infrastruktúra áll, de ez az adott controller és cloud platform megvalósításától függ. Érdemes ezért azt is megnézni, milyen cloud-erőforrásokat hoz létre az adott implementáció, és ezek milyen költséggel járnak. Tesztelés után ugyanúgy érdemes törölni őket, mint az éjszakára bekapcsolva hagyott fejlesztői VM-eket.

Aki a Service-ek után az Ingres-t, majd a Gateway API-t is megérti, az már tisztán látja, hogyan jut el egy kérés a felhasználótól a Pod-ig. Ez az a pont, ahol a Kubernetes hálózatkezelése összeáll egy egésszé.