Migrera från Ingress-NGINX till Gateway API i Kubernetes

för 1 dag sedan

I den här artikeln går vi igenom:

• Varför Gateway API växer fram som standard
• Vad som skiljer det från Ingress
• Hur en migrering kan gå till i praktiken
• Best-practice från Xenits egen plattform

Varför räcker inte Ingress-NGINX längre?

Ingress designades ursprungligen för relativt enkel HTTP-routing. Med tiden började man använda det till alltmer avancerade scenarier:

• Trafikdelning
• Avancerad routing
• Interna och externa entrypoints
• Säkerhetsregler
• Multi-tenancy

Mycket av detta löstes genom controller-specifika annotations, vilket fungera, men ledde till:

• Konfigurationer som blev svåra att förstå
• Låg portabilitet mellan implementationer
• Svårt att tydligt separera ansvar mellan team
• Beroende till specifika controllers

Det blev tydligt att ett mer standardiserat och strukturerat API behövdes.

Vad tillför Gateway API?

Gateway API introducerar en tydligare modell där olika delar av trafikhanteringen delas upp:

• GatewayClass – Definierar vilken implementation som används
• Gateway – Definierar entrypoints, portar, certifikat och exponeringsnivå
• Routes (t.ex. HTTPRoute) – Definierar hur trafik ska routas till tjänster

Detta gör att:

• Plattformsteam kan hantera infrastrukturen
• Applikationsteam kan definiera routing
• Konfigurationer blir tydligare och mer standardiserade

Se nedan exempel på rollindelning från Kubernetes-sigs.

Bild: https://gateway-api.sigs.k8s.io/

Skillnaden mellan Ingress-NGINX och Gateway API

En av de största förbättringarna är att Gateway API inte försöker vara en ”one-size-fits-all”-resurs som Ingress.

I stället är det designat för:

• Tydlig ansvarsfördelning
• Bättre stöd för multi-tenancy
• Avancerad routing utan speciallösningar
• Att fungera konsekvent mellan olika implementationer

Gateway API är också designat för att stödja fler protokoll och mer avancerade trafikmönster från början, snarare än att dessa funktioner läggs till i efterhand via annotations.

Hur implementerar man Gateway-API?

Gateway API är en standard, inte en färdig produkt. För att använda det behövs en controller.

Det finns flera alternativ, och valet beror ofta på:

• Befintlig infrastruktur
• Operativ modell
• Kompetens i organisationen

Några exempel på controllers:

• Nginx-gateway-fabric
• Envoy-gateway
• Istio-gateway

I vår plattform valde vi att använda Envoy Gateway, för att:

• Byggd för Gateway API – Envoy Gateway är designad med Gateway API som grundläggande komponent, vilket innebär snyggare och mer standardiserad konfiguration
• Stabil och modern dataplane – Envoy är en beprövad proxy med hög prestanda och bra stöd för observability och trafikhantering
• Enkel och framtidssäker plattform – Tydlig arkitektur, aktiv utveckling och nära koppling till Gateway API gör lösningen hållbar på lång sikt
• Etablerat Community och används av flera tech-jättar

Läs mer om hur vi installerar och konfigurerar den här: Xenit GitHub

Så migrerar du från Ingress-NGINX till Gateway-API

En viktig lärdom är att migrering från ingress-NGINX sällan är en “drop-in replacement”. Det är bättre att göra den stegvis. En typisk process ser ut så här:

Inventera befintliga Ingress-resurser

Kartlägg:

• Hostnames
• TLS-konfigurering
• Annotations
• Interna och externa endpoints

Detta ger en bild av vad som faktiskt används.

Sätt upp Gateway parallellt

Att köra båda lösningarna samtidigt under en period gör att:

• Nya tjänster kan gå på Gateway direkt
• Befintliga kan migreras gradvis
• Risk minskar

Detta var den strategi vi valde:

Migrera routing

Många regler går att översätta relativt rakt från Ingress till HTTPRoute, men vissa beteenden kräver att man tänker om lite särskilt sådant som tidigare låg i annotations.

Migrera DNS

DNS är ofta den mest känsliga delen av en migrering eftersom den påverkar faktisk trafik. För att göra detta förutsägbart tog vi fram en steg-för-steg-process som beskriver:

• Hur man förbereder ändringen
• Hur cutover görs
• Hur man verifierar att allt fungerar
• Hur rollback kan göras

Den finns publicerad här: Xenit GitHub

Gateway API lärdomar

Några saker blev tydliga under arbetet:

• Strukturen i Gateway API gör stora miljöer enklare att hantera. Det är fler resurser än Ingress, men uppdelningen och ansvarsfördelningen blir tydligare
• Mindre “magisk” konfiguration. Beteenden som tidigare låg i annotations blir mer explicita
• Stegvis migrering är nyckeln. Den tekniska förändringen är inte svår, men planering av trafikflytt och DNS är det som avgör hur smidig migreringen blir

Rekommendationer inför din Gateway-API migrering

Om ni fortfarande använder ingress-nginx kan det vara värt att börja med:

• Inventera era ingress-resurser
• Sätt upp Gateway API i testmiljö
• Migrera en tjänst end-to-end
• Dokumentera DNS-processen tidigt

Det gör resten av migreringen betydligt enklare.

Kubernetes Gateway API migration – få stöd av erfarna specialister

Övergången från ingress‑NGINX till Gateway API är mer än ett versionsbyte — det är ett skifte till en modernare, tydligare och mer skalbar modell för trafikhantering i Kubernetes. Gateway API ger en renare ansvarsfördelning, bättre stöd för avancerad routing och en standardiserad struktur som fungerar konsekvent mellan olika implementationer. Erfarenheten visar att en lyckad migrering handlar mindre om teknik och mer om planering: inventering, parallell drift och en kontrollerad DNS‑process är avgörande för ett smidigt resultat.

För organisationer som står inför samma resa kan vi vara en trygg partner. Vi har redan gjort detta i stora och komplexa miljöer och vet hur man undviker fallgroparna. Oavsett om ni vill börja i liten skala eller genomföra en fullständig migrering hjälper vi er att ta steget till Gateway API på ett säkert, effektivt och framtidssäkert sätt.

Nyheten är skriven av Carl Andersson, Specialist Engineer på Xenit.