Pianificazione di un upgrade

Questa pagina fornisce informazioni per aiutarti a pianificare un upgrade di Anthos Service Mesh. Ti consigliamo di consultare anche le note sull'upgrade di Istio.

Informazioni sugli upgrade canary

Ti consigliamo di eseguire l'upgrade di Anthos Service Mesh eseguendo prima un deployment canary del nuovo piano di controllo. Con un upgrade canary, asmcli installa una nuova revisione del piano di controllo insieme a quello precedente. Sia il piano di controllo precedente che quello nuovo sono etichettati con un'etichetta revision, che funge da identificatore per il piano di controllo.

Per eseguire la migrazione dei carichi di lavoro al nuovo piano di controllo:

  1. Imposta l'etichetta revision del nuovo piano di controllo su uno dei tuoi spazi dei nomi.

  2. Esegui un riavvio in sequenza. Il riavvio reinietta i proxy sidecar nei pod, in modo che i proxy utilizzino il nuovo piano di controllo.

  3. Monitora l'effetto dell'upgrade sui carichi di lavoro. Se necessario, ripeti i passaggi precedenti.

  4. Dopo aver testato l'applicazione, puoi eseguire la migrazione di tutto il traffico al nuovo piano di controllo o eseguire il rollback al piano di controllo precedente.

Un upgrade canary è molto più sicuro rispetto a un upgrade in loco in cui il nuovo piano di controllo sostituisce quello precedente. Per la procedura dettagliata, consulta Passare al nuovo piano di controllo.

Personalizzare il piano di controllo

Se hai personalizzato l'installazione precedente, hai bisogno delle stesse personalizzazioni per l'upgrade di Anthos Service Mesh. Se hai personalizzato l'installazione aggiungendo il flag --set values a istioctl install, devi aggiungere queste impostazioni a un file YAML IstioOperator, chiamato file overlay. Puoi specificare il file di overlay utilizzando l'opzione --custom_overlay con il nome file quando esegui asmcli.

Il pacchetto anthos-service-mesh in GitHub contiene molti file di overlay. Questi file contengono personalizzazioni comuni della configurazione predefinita. Puoi utilizzare questi file così come sono o apportarvi modifiche aggiuntive, se necessario. Alcuni file sono necessari per abilitare le funzionalità facoltative di Anthos Service Mesh. Il pacchetto anthos-service-mesh viene scaricato quando esegui asmcli per convalidare il progetto e il cluster.

Quando installi Anthos Service Mesh utilizzando asmcli install, puoi specificare uno o più file overlay con --option o --custom_overlay. Se non devi apportare modifiche ai file nel repository anthos-service-mesh, puoi utilizzare --option, e lo script recupera il file da GitHub. In caso contrario, puoi apportare modifiche al file dell'overlay e poi utilizzare l'opzione --custom_overlay per passarlo a asmcli.

Scegli un'autorità di certificazione

Se la tua attuale installazione di Anthos Service Mesh utilizza l'autorità di certificazione Anthos Service Mesh (Mesh CA) come autorità di certificazione (CA) per l'emissione di certificati di TLS reciproca (mTLS), ti consigliamo di continuare a utilizzare Mesh CA per i seguenti motivi:

  • Mesh CA è un servizio altamente affidabile e scalabile, ottimizzato per carichi di lavoro con scalabilità dinamica.
  • Con Mesh CA, Google gestisce la sicurezza e la disponibilità del backend della CA.
  • Mesh CA consente di fare affidamento su un'unica radice di attendibilità tra i cluster.

Se la tua attuale installazione di Anthos Service Mesh utilizza Istio CA (precedentemente nota come "Citadel"), puoi passare a Mesh CA quando esegui l'upgrade, ma devi pianificare il tempo di inattività. Durante l'upgrade, il traffico mTLS viene interrotto fino a quando tutti i carichi di lavoro non vengono passati all'utilizzo del nuovo piano di controllo con Mesh CA.

I certificati di Mesh CA includono i seguenti dati sui servizi dell'applicazione:

  • ID progetto Google Cloud
  • Lo spazio dei nomi GKE
  • Il nome dell'account di servizio GKE

Identificazione della CA

Quando esegui asmcli install per eseguire l'upgrade, specifichi la CA che asmcli deve abilitare sul nuovo piano di controllo.

La modifica delle CA causa tempi di inattività quando esegui il deployment dei carichi di lavoro sul nuovo piano di controllo. Se non puoi pianificare il tempo di inattività, assicurati di specificare la stessa CA per il nuovo piano di controllo utilizzato dal piano di controllo precedente. Se non sai quale CA è abilitata sulla tua rete mesh, esegui questi comandi:

  1. Recupera un elenco di pod da uno dei tuoi spazi dei nomi:

    kubectl get pods -n NAMESPACE

  2. Sostituisci POD_NAME con il nome di uno dei tuoi pod nel comando seguente:

    kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1

    Se Mesh CA è abilitato nello spazio dei nomi, vedrai il seguente output:

    - name: CA_ADDR
  value: meshca.googleapis.com:443

Prepara la configurazione del 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.

asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e gestire separatamente il piano di controllo e i gateway. Per ulteriori informazioni, consulta Installazione e upgrade dei gateway.

Eseguire l'upgrade della piattaforma (facoltativo)

Come best practice, devi eseguire l'upgrade di Anthos Service Mesh all'ultima versione supportata che supporta anche la tua piattaforma attuale. Quindi, esegui l'upgrade dell'ambiente in modo che rientri nell'intervallo delle piattaforme e delle versioni di Kubernetes supportate. Infine, se necessario, esegui l'upgrade all'ultima versione supportata di Anthos Service Mesh.

Che cosa succede dopo?