Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire la migrazione di Ingress all'API Gateway

Autopilot Standard

Questa pagina mostra come eseguire la migrazione della gestione del traffico su Google Kubernetes Engine (GKE) dall'API Ingress all'API Gateway. Gateway API fornisce una soluzione Google Cloud completamente gestita per la gestione del traffico delle applicazioni.

Per ridurre al minimo i tempi di inattività e mitigare i rischi, l'approccio più efficace per eseguire la migrazione all'API Gateway consiste nell'eseguire contemporaneamente sia la configurazione dell'API Ingress esistente sia quella della nuova API Gateway. Questo metodo consente di testare a fondo la nuova configurazione del gateway in un ambiente live senza influire sui servizi attuali. Dopo aver convalidato la nuova configurazione del gateway, puoi eseguire un rapido cutover DNS per reindirizzare il traffico all'API Gateway e contribuire a garantire una transizione fluida e a basso rischio.

A livello generale, la strategia di migrazione prevede le seguenti fasi:

Configura il nuovo bilanciatore del carico.
Definisci regole per la gestione del traffico in entrata.
Esegui il deployment della nuova configurazione e testa il flusso di traffico verso il nuovo indirizzo IP del gateway.
Trasferisci il traffico di produzione all'API Gateway.
Esegui la pulizia delle risorse Ingress rimanenti.

Configura il nuovo bilanciatore del carico

In questa fase, esegui il deployment di una risorsa Kubernetes Gateway per bilanciare il carico del traffico verso il cluster GKE. Quando esegui il deployment di una risorsa Gateway, GKE configura un bilanciatore del carico delle applicazioni di livello 7 per esporre il traffico HTTP(S) alle applicazioni eseguite nel cluster. Esegui il deployment di una risorsa Gateway per ogni cluster o per ogni bilanciatore del carico necessario.

Nell'esempio seguente, configuri un bilanciatore del carico delle applicazioni esterno globale. Per creare un gateway, salva il seguente manifest come gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

Il manifest precedente descrive un gateway che include i seguenti campi:

gatewayClassName: gke-l7-global-external-managed: specifica la GatewayClass per questo gateway. Questa classe Gateway utilizza un bilanciatore del carico delle applicazioni esterno globale.
protocol: HTTP e port: 80: specifica che il gateway espone la porta 80 per il traffico HTTP.

Definisci regole di traffico per il traffico in entrata

Le risorse di route definiscono regole specifiche del protocollo per mappare il traffico da un gateway ai servizi di backend.

In questa fase, traduci il manifest Ingress in una risorsa HTTPRoute. Per convertire il manifest Ingress, segui i passaggi descritti nello strumento ingress2gateway.

Questo esempio presuppone che tu disponga della seguente risorsa Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Dopo aver convertito il manifest utilizzando lo strumento ingress2gateway, l'output è il manifest HTTPRoute tradotto.

Salva il seguente manifest di esempio come httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Tieni presente che il campo rules nel manifest HTTPRoute corrisponde direttamente alle regole di routing definite nel manifest Ingress originale.

Eseguire il deployment e testare la nuova configurazione

In questa fase, applichi i manifest Gateway e HTTPRoute che hai creato nelle due fasi precedenti e verifichi che il traffico venga indirizzato al nuovo indirizzo IP del gateway.

Applica i manifest di Gateway e HTTPRoute:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Ottieni l'indirizzo IP del gateway. L'allocazione dell'indirizzo IP potrebbe richiedere alcuni minuti:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
L'output è l'indirizzo IP esterno del gateway, ad esempio 203.0.113.90.
Testa il nuovo indirizzo IP del gateway. Utilizza il seguente comando curl per inviare una richiesta all'indirizzo IP e specifica il nome host cafe.example.com. Ad esempio:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Sostituisci 203.0.113.90 con l'indirizzo IP esterno ottenuto dal passaggio precedente. L'output conferma che il nuovo indirizzo IP del gateway instrada correttamente il traffico per cafe.example.com senza eseguire una ricerca DNS.

Dirigere il traffico verso il nuovo indirizzo IP del gateway

In questa fase, trasferisci il traffico live dal precedente Ingress al nuovo gateway aggiornando i record DNS in modo che reindirizzino al nuovo indirizzo IP del gateway. I passaggi esatti per aggiornare i record DNS variano a seconda del provider DNS.

Ad esempio, se hai configurato cafe.example.com in Ingress, individua il record A per cafe.example.com con il tuo provider DNS e modifica il valore del vecchio indirizzo IP Ingress in 203.0.113.90, che è il nuovo indirizzo IP del gateway.

Dopo aver aggiornato il record DNS, il traffico inizia a spostarsi da Ingress a Gateway, ma il cutover non si verifica immediatamente per tutti i client. I resolver DNS che hanno memorizzato nella cache il record precedente attendono la scadenza del valore TTL (Time To Live) del record prima di eseguire nuovamente una query per il record e ricevere l'indirizzo IP aggiornato. Per questo motivo, devi continuare a eseguire l'Ingress esistente e il nuovo gateway in tandem finché non verifichi che il traffico verso l'Ingress è cessato, il che indica che la propagazione DNS è completata e i client non vengono più indirizzati al vecchio indirizzo IP. Puoi verificarlo monitorando il traffico sul bilanciatore del carico o sul controller Ingress. Per ulteriori informazioni, vedi Verifica della propagazione DNS.

Se utilizzi Cloud DNS, puoi utilizzare i pesi target per spostare in modo incrementale il traffico dal vecchio indirizzo IP al nuovo. Per ulteriori informazioni, consulta Configurare le policy di routing DNS e i controlli di integrità.

Esegui la pulizia delle risorse Ingress rimanenti

Dopo aver verificato che il nuovo gateway funzioni correttamente, pulisci le vecchie risorse Ingress.

Elimina la risorsa Ingress:
```
kubectl delete ingress cafe-ingress
```
Disinstalla il controller ingress-nginx. Ad esempio, se hai utilizzato Helm per installare il controller, esegui il seguente comando:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Confronto delle funzionalità tra Ingress NGINX e GKE Gateway

L'API Gateway fornisce un modo più standardizzato per configurare l'ingresso e ha parità di funzionalità per le funzionalità più comuni come routing, intestazioni e suddivisione del traffico.

La seguente tabella mette a confronto le annotazioni utilizzate per le funzionalità comuni nel controller Ingress e nell'API Gateway.

Funzionalità	Annotazione in Ingress	Annotazione nel gateway GKE	Parità
Riscritture degli URL	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` con un filtro `urlRewrite`.	Parità parziale. GKE Gateway supporta solo le sostituzioni dei prefissi.
Manipolazione dell'intestazione	`nginx.ingress.kubernetes.io/proxy-set-headers` o `add-headers`	`HTTPRoute` con un modificatore `requestHeaderModifier` o un filtro `responseHeaderModifier`.	Parità completa.
Routing basato su percorso	`spec.rules.http.paths` nell'oggetto Ingress.	`rules.matches.path` nell'oggetto HTTPRoute.	Parità completa.
Routing basato sull'host	`spec.rules.host` nell'oggetto Ingress.	`hostnames` nell'oggetto HTTPRoute.	Parità completa.
Suddivisione del traffico	`nginx.ingress.kubernetes.io/canary` annotazioni.	`HTTPRoute` con `backendRefs` ponderata.	Parità completa. Inoltre, puoi suddividere il traffico con un controllo granulare.
Autenticazione	`nginx.ingress.kubernetes.io/auth-url` per l'autenticazione esterna.	Identity-Aware Proxy (IAP): `BackendPolicy` CRD. Altro: richiede un approccio più personalizzato, possibilmente con mesh di servizi o filtri personalizzati.	Parità parziale. Identity-Aware Proxy è il metodo consigliato per proteggere il gateway ed è configurato nel backend.

Passaggi successivi

Scopri come proteggere il tuo gateway.
Scopri come funziona la gestione del traffico del gateway.