Gateway API

Gateway API

NodePort na každou aplikaci se nedá udržet: skončíte tím, že si pamatujete, že e-shop je na 30080 a wiki na 30081. Chcete jeden HTTP vstupní bod, který směruje podle jména hosta a cesty.

Kubernetes na to má dvě odpovědi. Ingress je ta stará – stabilní, ale zmrazená: každý controller si ji rozšířil vlastními anotacemi, takže rewrite pravidlo pro nginx neznamená pro Traefik nic. Gateway API je náhrada: tatáž úloha vyjádřená skutečnými typovanými objekty, a veškerý vývoj teď probíhá tam.

graph LR C[Prohlížeč<br/>shop.k8s.lab] --> GW[Gateway<br/>listener :80] GW --> R1[HTTPRoute shop] GW --> R2[HTTPRoute wiki] R1 --> S1[Service shop] R2 --> S2[Service wiki] GC[GatewayClass<br/>která implementace] -.-> GW

Tři objekty, tři vlastníci

ObjektOdpovídá naObvykle vlastní
GatewayClasskterá implementace to obslouží?správce clusteru, instaluje se s controllerem
Gatewaykudy provoz vstupuje – porty, protokoly, TLSplatform tým
HTTPRoutekteré požadavky na kterou Serviceaplikační tým

To rozdělení je hlavní přínos. U Ingressu jeden objekt míchal infrastrukturu s aplikací, takže buď vývojáři editovali sdílenou infrastrukturu, nebo se z platform týmu stala fronta na tikety. Tady tým vlastní svou HTTPRoute a připojí ji ke Gateway, kterou smí použít – a Gateway přes allowedRoutes rozhoduje, kdo se smí připojit.

Objekty

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
spec:
  parentRefs:
    - name: web-gw
  hostnames: ["shop.k8s.lab"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: shop-svc
          port: 80

HTTPRoute se ke Gateway připojí sama přes parentRefs – route ukazuje nahoru, Gateway své routy nevyjmenovává. Právě díky tomu může tým přidat routu, aniž by sahal na sdílenou konfiguraci.

Co Ingress vyjádřit neuměl

  • Rozdělení provozu – dva backendRefs s vahami, takže canary 90/10 je běžné pole, ne anotace.
  • Shoda podle hlaviček, metody a query – nejen podle hosta a cesty.
  • Přepisování hlaviček a redirecty jako typované filtry.
  • Další protokoly – TCPRoute, GRPCRoute, TLSRoute.
  • Směrování napříč namespacy s výslovným modelem oprávnění.
      backendRefs:                # canary, žádné anotace
        - name: shop-v1
          port: 80
          weight: 90
        - name: shop-v2
          port: 80
          weight: 10

Pořád to jsou dva kusy

Objekty jsou jen data. Musí být nainstalovaný controller, který je čte a provozuje proxy – NGINX Gateway Fabric, Envoy Gateway, Traefik, Cilium nebo cloudový load balancer. A na rozdíl od Ingressu nejsou CRD součástí Kubernetes: nejdřív instalujete CRD Gateway API, pak controller. Lab 15 dělá obojí.

Gateway bez controlleru zůstane PROGRAMMED: False a neteče přes ni nic – stejné tiché selhání jako u Ingressu bez controlleru, jen vám to aspoň řekne stavové pole.

A samotný controller jsou dvě věci, což je dobré vědět, než ho půjdete hledat:

Kde žijeTyp Service
Řídicí rovinanamespace, do kterého jste chart nainstalovaliClusterIP – mluví jen se svými agenty
Datová rovina (vlastní proxy)vzniká na každou Gateway, v jejím namespaceto, co jste nastavili: NodePort nebo LoadBalancer

Dokud tedy nevytvoříte Gateway, žádná proxy neexistuje – a když ji vytvoříte, neobjeví se vedle controlleru. Hledat NodePort v namespace controlleru a najít tam ClusterIP je u téhle implementace nejčastější falešný poplach.

Kudy sem provoz přiteče

Controller potřebuje vlastní vstupní bod. V cloudu je to LoadBalancer Service, v tomhle clusteru NodePort – prohlížeč tedy mluví na http://worker01:<nodeport> s hlavičkou Host:.

Má se ještě učit Ingress?

Potkáte ho – je v každém existujícím clusteru a nikam se neruší. Nová práce ale patří na Gateway API a většina controllerů umí během migrace číst obojí.

Reference