Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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 completamente gestita Google Cloud 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 le configurazioni dell'API Ingress esistente e della nuova API Gateway. Questo metodo consente di testare in modo approfondito 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.
Passa 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 tuo 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 in esecuzione nel cluster. Esegui il deployment di una risorsa Gateway per ogni cluster o per ogni bilanciatore del carico necessario.

Nell'esempio seguente, configurerai 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 instradamento definite nel manifest Ingress originale.

Esegui il deployment e testa 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. Potrebbero essere necessari alcuni minuti per allocare l'indirizzo IP:
```
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 gateway. Utilizza il seguente comando curl per inviare una richiesta all'indirizzo IP e specificare 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 che hai 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 al nuovo indirizzo IP del gateway

In questa fase, esegui il cutover del traffico in tempo reale dal tuo Ingress precedente al nuovo Gateway aggiornando i record DNS in modo che puntino 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, devi individuare il record A per cafe.example.com presso il tuo provider DNS e modificare il valore del vecchio indirizzo IP di Ingress in 203.0.113.90, che è il nuovo indirizzo IP del gateway.

Dopo l'aggiornamento del 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 Time To Live (TTL) 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'ingresso esistente e il nuovo gateway in tandem finché non verifichi che il traffico verso l'ingresso è cessato, il che indica che la propagazione DNS è completa 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 saperne di più, consulta Verifica della propagazione DNS.

Se utilizzi Cloud DNS, puoi utilizzare i pesi di destinazione per spostare gradualmente il traffico dal vecchio indirizzo IP al nuovo. Per saperne di più, consulta Configura 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 questo comando:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Confronto delle funzionalità tra Ingress NGINX e gateway GKE

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

La seguente tabella confronta la configurazione utilizzata per le funzionalità comuni nel controller Ingress e nell'API Gateway.

Funzionalità	Annotazione in Ingress	Configurazione nel gateway GKE	Parità
Routing basato sull'host	Il campo `spec.rules.host` nell'oggetto Ingress.	Il campo `hostnames` nell'oggetto HTTPRoute.	Parità completa.
Routing basato su percorso	Il campo `spec.rules.http.paths` nell'oggetto Ingress.	Il campo `rules.matches.path` nell'oggetto HTTPRoute.	Parità completa.
Suddivisione del traffico	`nginx.ingress.kubernetes.io/canary` annotazioni.	HTTPRoute con il campo ponderato `backendRefs`.	Parità completa. Inoltre, puoi suddividere il traffico con un controllo granulare.
Affinità di sessione	`nginx.ingress.kubernetes.io/affinity` e `nginx.ingress.kubernetes.io/affinity-mode` annotazioni.	GCPTrafficDistributionPolicy con il campo `sessionAffinity`.	Parità completa. Il gateway GKE supporta più tipi di affinità sessione, tra cui i tipi di affinità basati su cookie (`HTTP_COOKIE`, `GENERATED_COOKIE` e stateful `STRONG_COOKIE_AFFINITY`), l'affinità basata su intestazione (`HEADER_FIELD`) e l'affinità basata su IP client (`CLIENT_IP`).
CORS (condivisione di risorse multiorigine)	`nginx.ingress.kubernetes.io/enable-cors`	HTTPRoute con un filtro `CORS`.	Parità completa. Nota: il gateway GKE impone limiti al numero di pattern con caratteri jolly che puoi definire per listener o nome host
Riscritture URL	`nginx.ingress.kubernetes.io/rewrite-target`	HTTPRoute con un filtro `urlRewrite`.	Parità parziale. Il gateway GKE supporta solo le sostituzioni dei prefissi.
Manipolazione delle intestazioni	`nginx.ingress.kubernetes.io/proxy-set-headers` o `add-headers`	HTTPRoute con un modificatore `requestHeaderModifier` o un filtro `responseHeaderModifier`.	Parità completa.
Autenticazione	`nginx.ingress.kubernetes.io/auth-url` per l'autenticazione esterna.	Identity-Aware Proxy (IAP): risorsa personalizzata GCPBackendPolicy. Altro: richiede un approccio più personalizzato, possibilmente con mesh di servizi o filtri personalizzati.	Parità parziale. Identity-Aware Proxy è il modo consigliato per proteggere il gateway ed è configurato sul backend.

Passaggi successivi

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