Installazione ed upgrade dei gateway

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e gestire gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro della rete mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono un controllo granulare sul traffico in entrata e in uscita dal mesh. I gateway vengono utilizzati principalmente per gestire il traffico in entrata, ma puoi anche configurarli per gestire altri tipi di traffico. Ad esempio:

• Gateway in uscita: un gateway in uscita consente di configurare un nodo di uscita dedicato per il traffico che esce dal mesh, in modo da limitare i servizi che possono o devono accedere alle reti esterne oppure di abilitare il controllo sicuro del traffico in uscita per aggiungere sicurezza al mesh, ad esempio.

• Gateway est-ovest: un proxy per il traffico est-ovest che consente ai carichi di lavoro dei servizi di comunicare oltre i confini dei cluster in una rete mesh multi-primaria su reti diverse. Per impostazione predefinita, questo gateway sarà pubblico su Internet.

In questa pagina vengono descritte le best practice per il deployment e l'upgrade dei proxy del gateway, nonché esempi di configurazione dei proxy gateway istio-ingressgateway e istio-egressgateway. Elementi come la suddivisione del traffico, i reindirizzamenti e la logica per i nuovi tentativi sono possibili applicando una configurazione di gateway ai proxy del gateway. Quindi, invece di aggiungere il routing del traffico a livello di applicazione (L7) alla stessa risorsa API, associa un servizio virtuale al gateway. Ciò consente di gestire il traffico del gateway come qualsiasi altro traffico del piano dati nel mesh di servizi.

Puoi eseguire il deployment dei gateway in diversi modi e scegliere di utilizzare più di una topologia all'interno dello stesso cluster. Consulta Topologie di deployment dei gateway nella documentazione di Istio per saperne di più su queste topologie.

Best practice per il deployment dei gateway

1. Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
2. Come best practice per la sicurezza, consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal piano di controllo.
3. Utilizza l'inserimento automatico dei file collaterali (inserimento automatico) per inserire la configurazione proxy per i gateway nello stesso modo in cui inserisci i proxy sidecar per i tuoi servizi.

Queste best practice:

• Consenti agli amministratori dello spazio dei nomi di gestire i gateway senza bisogno di privilegi elevati per l'intero cluster.
• Consenti agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment che utilizzano per gestire le applicazioni Kubernetes di cui eseguire il deployment e gestire gateway.
• Fornisce agli amministratori il controllo completo sul deployment del gateway e semplifica le operazioni. Quando è disponibile un nuovo upgrade o una configurazione è cambiata, gli amministratori aggiornano i pod gateway semplicemente riavviandoli. In questo modo, l'utilizzo di un deployment gateway è lo stesso dell'utilizzo dei proxy sidecar per i servizi.

Esegui il deployment dei gateway

Per supportare gli utenti con strumenti di deployment esistenti, Anthos Service Mesh supporta gli stessi modi per eseguire il deployment di un gateway come Istio: IstioOperator, Helm e YAML di Kubernetes. Ogni metodo produce lo stesso risultato. Anche se puoi scegliere il metodo con cui hai più familiarità, ti consigliamo di usare il metodo YAML di Kubernetes perché è più facile da modificare e puoi archiviare manifest idrati nel controllo del codice sorgente.

1. Crea uno spazio dei nomi per il gateway, se non ne hai già uno. Sostituisci GATEWAY_NAMESPACE con il nome del tuo spazio dei nomi.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. Puoi abilitare l'inserimento automatico sul gateway applicando un'etichetta di revisione allo spazio dei nomi del gateway. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i proxy inseriti a una determinata revisione del piano di controllo. L'etichetta di revisione da utilizzare dipende dal fatto che tu abbia eseguito il deployment del piano di controllo gestito da Google o del piano di controllo nel cluster.

   Gestita da Google

   Per il piano di controllo gestito da Google, l'etichetta di revisione corrisponde a un canale di rilascio:

   Etichetta revisione	Canale
   istio.io/rev=asm-managed	Normale
   istio.io/rev=asm-managed-rapid	Rapida
   istio.io/rev=asm-managed-stable	Stabile

   Lo spazio dei nomi del gateway può trovarsi sullo stesso canale di rilascio dei servizi o su un canale di rilascio diverso. Ti consigliamo di usare lo stesso canale di rilascio su un cluster. Per vedere quale canale di rilascio sta utilizzando uno spazio dei nomi:

   kubectl get namespace NAMESPACE -L istio.io/rev
   

   Nel cluster

   Per i piani di controllo nel cluster, il servizio e il deployment istiod hanno in genere un'etichetta di revisione simile a istio.io/rev=asm-1106-2, dove asm-1106-2 identifica la versione di Anthos Service Mesh. La revisione diventa parte del nome del servizio istiod, ad esempio: istiod-asm-1106-2.istio-system

   Utilizza il comando seguente per individuare l'etichetta di revisione su istiod per il piano di controllo nel cluster:

   kubectl get deploy -n istio-system -l app=istiod -o jsonpath="{.items[*].metadata.labels.'istio\.io\/rev'}"'{"\n"}'
   

3. Abilita lo spazio dei nomi per l'inserimento. Sostituisci e REVISION con il valore dell'etichetta di revisione.

   kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

   Puoi ignorare il messaggio "istio-injection not found" nell'output. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection, cosa che dovresti aspettarti nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichetta istio-injection.

4. Se hai installato Anthos Service Mesh utilizzando asmcli, passa alla directory specificata in --output_dir, quindi cd alla directory samples.

   Importante: per assicurarti di essere nella directory samples corretta, esegui il comando ls per elencare i contenuti della directory e verifica che esista una directory gateways (a cui potrai accedere nel passaggio successivo) e una online-boutiquedirectory.

   Se non hai eseguito l'installazione utilizzando asmcli, copia i file di configurazione per i gateway dal repository anthos-service-mesh.

5. Puoi eseguire il deployment della configurazione del gateway di esempio che si trova nella directory samples/gateways/ così com'è o modificarla in base alle tue esigenze.

   In entrata

   kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-ingressgateway
   

   In uscita

   kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-egressgateway
   

6. Dopo aver creato il deployment, verifica che i nuovi servizi funzionino correttamente:

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   Verifica che l'output sia simile al seguente:

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Importante: le risorse gateway dovrebbero essere gestite come qualsiasi altra applicazione Kubernetes. Gli esempi nel repository anthos-service-mesh-packages sono pensati come guida e guida rapida e devono essere personalizzati in base alle esigenze.

Selettori gateway

Puoi applicare una configurazione del gateway ai proxy istio-ingressgateway e istio-egressgateway per gestire il traffico in entrata e in uscita per il tuo mesh, in modo da specificare il traffico in entrata o in uscita dal mesh. Le etichette sui pod di deployment di un gateway vengono utilizzate dalle risorse di configurazione del gateway, pertanto è importante che il selettore gateway corrisponda a queste etichette.

Ad esempio, nei deployment precedenti, l'etichetta istio=ingressgateway viene impostata sui pod gateway. Per applicare una configurazione gateway a questi deployment, devi selezionare la stessa etichetta:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Per un esempio di configurazione gateway e servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Online Boutique.

Upgrade dei gateway

Upgrade in loco

Per la maggior parte dei casi d'uso, devi eseguire l'upgrade dei gateway seguendo il modello di upgrade in loco. Poiché i gateway utilizzano l'inserimento dei pod, i nuovi pod del gateway creati verranno inseriti automaticamente con la configurazione più recente, che include la versione.

Se vuoi modificare la revisione del piano di controllo in uso da parte del gateway, puoi impostare l'etichetta istio.io/rev sul deployment del gateway, che attiverà anche un riavvio in sequenza.

Piano di controllo gestito da Google
Poiché Google gestisce gli upgrade del piano di controllo per il piano di controllo gestito da Google, puoi semplicemente riavviare il deployment del gateway e i nuovi pod verranno inseriti automaticamente con la configurazione e la versione più recenti.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Piano di controllo nel cluster
Per applicare lo stesso pattern ai gateway quando hai il piano di controllo nel cluster, devi modificare la revisione del piano di controllo utilizzata dal gateway. Imposta l'etichetta istio.io/rev sul deployment del gateway che attiverà un riavvio in sequenza.

1. Aggiorna l'etichetta della revisione nello spazio dei nomi o nel pod gateway.
   • Se hai etichettato lo spazio dei nomi per l'inserimento:
   • Imposta l'etichetta istio.io/rev sullo spazio dei nomi sul nuovo valore di revisione

kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=REVISION \
  --overwrite

OPPURE

• Se hai abilitato l'inserimento solo per il pod del gateway:
  • Imposta l'etichetta istio.io/rev sul deployment sul nuovo valore di revisione.
    • YAML per Kubernetes

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

Upgrade a Canary (avanzato)

Se utilizzi il piano di controllo nel cluster e vuoi controllare più lentamente l'implementazione di una nuova revisione del piano di controllo, puoi seguire il pattern di upgrade canary. Puoi eseguire più versioni di un deployment gateway e assicurarti che tutto funzioni come previsto con un sottoinsieme del tuo traffico. Ad esempio, se vuoi implementare una nuova revisione, canary, crea una copia del deployment del gateway con l'etichetta istio.io/rev=REVISION impostata sulla nuova revisione e con un nuovo nome, ad esempio istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Quando questo deployment viene creato, avrai due versioni del gateway, entrambe selezionate dallo stesso servizio:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Nota: a differenza dei servizi per le applicazioni di cui è stato eseguito il deployment all'interno del mesh, non puoi utilizzare lo spostamento del traffico Istio per distribuire il traffico tra le versioni dei gateway perché proviene direttamente da client esterni che Istio non controlla. Puoi invece controllare la distribuzione del traffico in base al numero di repliche di ogni deployment. Se utilizzi un altro bilanciatore del carico prima di Istio, puoi utilizzarlo anche per controllare la distribuzione del traffico.

Se ritieni che le tue applicazioni funzionino come previsto, esegui questo comando per passare alla nuova versione eliminando il deployment con il vecchio set di etichette Istio.io/rev:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Se si è verificato un problema durante il test dell'applicazione con la nuova versione del gateway, esegui questo comando per tornare alla versione precedente eliminando il deployment con il nuovo set di etichette istio.io/rev:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE