Migreren van Ingress naar API Gateway in Kubernetes

De Evolutie van Traffic Management in Kubernetes

Jarenlang was de Ingress resource de standaardmanier om services in een Kubernetes-cluster te ontsluiten. Het was eenvoudig, effectief en voldeed prima in de begindagen van cloud-native ontwikkeling. Naarmate architecturen complexer werden-met multi-cluster opstellingen, fijnmazige traffic splitting en geavanceerde beveiligingseisen-kwamen de beperkingen van de standaard Ingress resource echter aan het licht.

Maak kennis met de Kubernetes Gateway API. Dit is niet zomaar een vervanging, maar een complete evolutie van hoe we North-South verkeer afhandelen. Het biedt een expressievere, uitbreidbare en rol-georiënteerde set resources om verkeer te beheren.

Waarom Migreren?

De standaard Ingress resource is vrij beperkt. Om iets meer te bereiken dan eenvoudige pad-gebaseerde routing, moesten ontwikkelaars vaak vertrouwen op annotaties die specifiek zijn voor hun Ingress-controller (zoals Nginx). Dit leidde tot "annotation hell," waarbij de configuratie niet portabel en moeilijk te onderhouden was.

Belangrijkste Voordelen van API Gateway (Gateway API):

• Rol-georiënteerd: Het scheidt infrastructuurzaken (GatewayClass, Gateway) van applicatie-routing (HTTPRoute), waardoor infra- en app-teams onafhankelijk kunnen werken.
• Expressiviteit: Standaard ondersteuning voor routing op basis van headers, traffic splitting (canary releases) en redirects zonder aangepaste annotaties.
• Uitbreidbaarheid: Gebouwd om te worden uitgebreid met custom resources (Policy attachment) voor specifieke vendor-functies, terwijl de kernlogica gestandaardiseerd blijft.
• Portabiliteit: Wissel tussen verschillende implementaties (Kong, Traefik, Istio) zonder je hele configuratie te herschrijven, omdat de kern-resources gestandaardiseerd zijn.

Snel overzicht: Ingress vs. Gateway API

Hoe te Migreren: Het Transitiepad

Migreren betekent niet dat je alles van de ene op de andere dag moet vervangen. De Gateway API kan naast je bestaande Ingress-controllers bestaan. De transitie volgt meestal deze stappen:

1. Installeer een Gateway API Controller: De meeste moderne controllers (Traefik v3, Kong, Istio) ondersteunen nu beide.
2. Definieer een GatewayClass en Gateway: Dit vertegenwoordigt het toegangspunt (de "Load Balancer").

# Defining the entry point
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same

3. Maak HTTPRoutes aan: Vertaal je Ingress-regels naar HTTPRoute resources. Hier map je paden en hosts naar services.

# Mapping traffic to your service
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
spec:
  parentRefs:
  - name: main-gateway
  hostnames:
  - "app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-api-service
      port: 80

4. Geleidelijke Traffic Shift: Gebruik je DNS of een externe load balancer om het verkeer langzaam te verplaatsen van het Ingress IP naar het nieuwe Gateway IP.

Van Ingress naar HTTPRoute: Een Concreet Voorbeeld

Om de verandering te begrijpen, kijken we naar hoe een standaard Ingress-manifest wordt vertaald naar de Gateway API. Merk op dat de configuratie schoner is en controller-specifieke annotaties vermijdt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: api.neneos.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "api.neneos.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefix: /
    backendRefs:
    - name: api-service
      port: 80

Geavanceerde Configuratie & Ontbrekende Stukken

1. Cross-Namespace Routing (ReferenceGrant)

Een van de krachtigste functies van de Gateway API is de mogelijkheid voor een Gateway in de ene namespace om verkeer te routeren naar een Service in een andere namespace. Om beveiligingsrisico's te voorkomen, introduceert de Gateway API de ReferenceGrant resource. Deze moet worden aangemaakt in de doel namespace (waar de Service leeft) om de Gateway expliciet toestemming te geven ernaar te verwijzen.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-to-service
  namespace: prod-apps
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: Gateway
    namespace: infrastructure
  to:
  - group: ""
    kind: Service

2. TLS/SSL Certificaatbeheer

In de Gateway API wordt TLS geconfigureerd op het niveau van de Gateway (de listener). Als je cert-manager gebruikt, is de integratie naadloos via annotaties op de Gateway-resource, vergelijkbaar met hoe je dat bij Ingress deed.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: neneos-com-tls

3. Annotaties vervangen door Filters

Standaardfuncties zoals CORS, Rate Limiting en Header-manipulatie worden nu afgehandeld door Filters binnen de HTTPRoute. Dit elimineert de "annotation hell" van specifieke vendors. De meeste moderne controllers zoals Kong of Traefik implementeren deze filters native als onderdeel van de specificatie.

Hier is een voorbeeld van veelvoorkomende filterpatronen voor header-manipulatie en redirects:

# Header Manipulatie & Redirect Voorbeeld
rules:
- matches:
  - path: { type: PathPrefix, value: /old-api }
  filters:
  - type: RequestHeaderModifier
    requestHeaderModifier:
      add:
      - name: x-gateway-source
        value: "k8s-gateway"
      remove: ["x-internal-token"]
  - type: RequestRedirect
    requestRedirect:
      scheme: https
      statusCode: 301

4. End-to-End Encryptie (BackendTLSPolicy)

Waar Ingress vaak de TLS-terminatie aan de rand afhandelde, introduceert de Gateway API BackendTLSPolicy voor veilige communicatie tussen de Gateway en de backend-service. Dit maakt volledige end-to-end encryptie mogelijk met gebruik van aangepaste CA's of verstrekte certificaten, wat in sommige gevallen voldoet aan strikte compliance-eisen zonder dat een volledige service mesh nodig is.

Observability en Operations

Voor platformbeheerders biedt de Gateway API duidelijke statusrapportage. Elke resource heeft een status-blok dat inzicht geeft in eventuele routeringsfouten, zoals een hostnaamconflict, een ontbrekende backend of een configuratiefout. Bovendien integreren Gateway API-implementaties (zoals Istio of Envoy Gateway) direct met Prometheus en Grafana voor inzicht in doorvoer, latency en foutpercentages.

Roll-out Strategie

Bij de overstap raden we een parallelle implementatie aan:

• Houd je Ingress-controller actief.
• Implementeer de Gateway API-controller en je HTTPRoutes.
• Test de nieuwe Gateway met zijn eigen LoadBalancer IP of een tijdelijke DNS-verwijzing.
• Zodra alles is gevalideerd, update je de productie DNS-records. Houd rekening met de DNS TTL; verlaag deze naar 60-300 seconden vóór de overstap om snelle rollbacks mogelijk te maken.

Mogelijke Moeilijkheden & Best Practices

Elke migratie brengt uitdagingen met zich mee. Let bij de overstap naar de Gateway API op het volgende:

• Leercurve: Er zijn meer resource-types om te beheren (Gateway, HTTPRoute, ReferenceGrant) vergeleken met een enkel Ingress-bestand. Begin met een kleine, niet-kritieke service om te wennen aan de hiërarchie.
• Versiecompatibiliteit: Zorg ervoor dat je Kubernetes-versie (1.24+) en je controller-versie de Gateway API-specificaties volledig ondersteunen. Controleer of de controller het 'Standard' of 'Experimental' kanaal van de API ondersteunt.
• CRD Installatie: In tegenstelling tot Ingress zijn de Gateway API CRD's vaak niet standaard geïnstalleerd in oudere clusters. Je moet ze mogelijk handmatig installeren met de officiële manifesten.
• Feature Parity: Sommige zeer gespecialiseerde Nginx-modules of Lua-scripts hebben mogelijk nog geen directe 1:1 filter-equivalent. Zoek in die gevallen naar vendor-specifieke ExtensionRef filters.

Best Practices voor een Soepele Overstap:

• Automatiseer de Vertaling: Gebruik tools zoals ingress2gateway (een SIG-Network project) om je eerste HTTPRoute-manifesten te genereren op basis van bestaande Ingress-resources.
• Namespace Strategie: Houd je Gateway resources in een speciale infrastructure namespace en je HTTPRoutes in dezelfde namespace als je applicaties.
• Valideer met Admission Webhooks: Zorg ervoor dat de admission webhook van je Gateway-controller is ingeschakeld om configuratiefouten op te vangen voordat ze worden toegepast.

"De Gateway API vertegenwoordigt de belangrijkste verbetering in Kubernetes networking sinds de start, waarbij we evolueren van 'goed genoeg' naar 'production-grade' traffic management."

De Oude Garde: Nginx Ingress

De NGINX Ingress Controller is momenteel de meest gebruikte ingress-oplossing. Het is robuust en beproefd. De sterke afhankelijkheid van annotaties voor Layer 7-functies is echter precies wat de Gateway API wil oplossen.

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

Hoewel Nginx inmiddels ondersteuning heeft voor de Gateway API, grijpen veel organisaties deze migratie aan om naar modernere, native oplossingen te kijken.

De Top 3 API Gateway Oplossingen

Als je verder wilt kijken dan standaard Ingress, zijn dit de drie populairste oplossingen in het ecosysteem op dit moment:

1. Kong: Een veteraan in de API Gateway-wereld. Kong voor Kubernetes biedt ongelooflijke prestaties en een uitgebreid ecosysteem van plug-ins voor authenticatie, rate limiting en observability.
2. Istio: Hoewel primair een service mesh, is de Gateway-implementatie van Istio een van de meest volwassen oplossingen. Het is de beste keuze als je diepgaande beveiliging en observability nodig hebt over je hele microservices-landschap.
3. Traefik: Bekend om zijn eenvoud en dynamische configuratie. Traefik v3 heeft eersteklas ondersteuning voor de Gateway API en is uitzonderlijk eenvoudig op te zetten met moderne CI/CD-pipelines.

Azure AKS en de Gateway API

Voor degenen die op Azure Kubernetes Service (AKS) draaien, heeft Microsoft flink geïnvesteerd in dit gebied. Traditioneel was AGIC (Application Gateway Ingress Controller) de standaard voor integratie met Azure Application Gateway.

Tegenwoordig biedt Azure de Application Gateway for Containers (ALB), een volledig beheerde service die de Kubernetes Gateway API implementeert. Dit biedt een hoogwaardig, schaalbaar toegangspunt dat door Azure wordt beheerd, maar volledig via standaard Kubernetes-manifesten wordt aangestuurd. Het is het aanbevolen pad voor nieuwe AKS-implementaties die zoeken naar native Azure-integratie met moderne standaarden.