Blog članak

Kubernetes Gateway API 2026: Vodič za migraciju s Ingress-a

Praktičan vodič za prijelaz s Ingress-NGINX kontrolera na Kubernetes Gateway API, uz korake konverzije, provjere kompatibilnosti i plan preusmjeravanja prometa.

Kubernetes promet se preusmjerava s Ingress pristupnika na Gateway i HTTPRoute resurse.

Kubernetes Gateway API je zreli, GA nasljednik starijeg Ingress API-ja. Povod za promjenu 2026. godine je umirovljenje Ingress-NGINX kontrolera u ožujku. Postojeće instalacije nastavljaju raditi, ali više ne dobivaju nova izdanja, ispravke grešaka ni sigurnosna ažuriranja. Ovo nije rok za sam Ingress API. To je razlog za odabir podržanog kontrolera i planiranje prijelaza prije nego što trenutni kontroler postane rizik za incidente.

Ingress stavlja većinu namjere usmjeravanja u jedan resurs i često se oslanja na anotacije specifične za kontroler. Gateway API razdvaja vlasništvo. GatewayClass odabire implementaciju kontrolera, Gateway definira listenere i TLS, a HTTPRoute pridružuje pravila usmjeravanja aplikacije listeneru putem parentRefs. To razdvajanje omogućuje platformskom timu vlasništvo nad Gatewayem dok aplikacijski tim posjeduje svoj HTTPRoute. Kompromis je veći broj objekata za upravljanje i pregled kompatibilnosti za svaku anotaciju.

Prvo instalirajte Gateway API CRD-ove i dokumentiranu verziju kontrolera. Izdanje API-ja neovisno je o verziji Kubernetesa. U srpnju 2026. projekt je naveo v1.6.1 u Standard kanalu, ali kontroler može podržavati uži raspon značajki Gateway API-ja. Fiksirajte izdanje CRD-ova i sliku kontrolera u Gitu, zatim zabilježite podržani kanal u bilješkama o migraciji. Eksperimentalne ili Extended značajke zahtijevaju zasebnu provjeru; ne pretpostavljajte da Standard resurs podržava sve implementacijski specifične opcije.

Minimalni HTTP listener i ruta mogu izgledati ovako:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: edge
spec:
  gatewayClassName: example-controller
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: app.example.com
    tls:
      mode: Terminate
      certificateRefs:
      - name: app-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app
  namespace: app
spec:
  parentRefs:
  - name: public
    namespace: edge
    sectionName: https
  hostnames: ["app.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api
      port: 8080

Pokrenite SIG Networkov ingress2gateway v1.0 pomoćnik protiv postojećih manifesta. Pregledajte njegova upozorenja umjesto da generirani YAML tretirate kao gotovu migraciju. Prepišite anotacije za ograničenja brzine, autentifikaciju, manipulaciju zaglavljima ili isječke prema dokumentaciji novog kontrolera. Prepisivanje koje samo provjerava 200 odgovora može propustiti TLS SNI greške, petlje preusmjeravanja, rukovanje WebSocketom, ograničenja veličine zahtjeva i zahtjeve cross-namespace ReferenceGrant.

Pokrenite novi kontroler uz Ingress u razvojnom klasteru. Usporedite statusne uvjete, obnovu certifikata, pristupne dnevnike, timeoutove uzvodno i metrike za istu testnu matricu. Koristite canary hostname ili ponderirani DNS/load-balancer cilj za prvi produkcijski promet. Postupno prebacujte, pratite stopu pogrešaka i latenciju te zadržite staru rutu dostupnom za povratak. Izbrišite Ingress resurse i deinstalirajte Ingress-NGINX tek nakon što je novi Gateway put poslužio stvarni promet kroz jedan potpuni prozor za povratak.

Izvori: izdanje ingress2gateway v1.0, povlačenje Ingress-NGINX-a, Migracija s Ingressa, Gateway API izdanja.

Povezana područja

Ova su područja rada usklađena s temom članka i daju čišći prijelaz od edukativnog sadržaja do konkretne implementacije.

Nastavite čitati

Prvo po zajedničkim kategorijama, a zatim po najjačem preklapanju u tagovima.