Revisioni del control plane Cloud Service Mesh

Questa pagina descrive il funzionamento delle revisioni del control plane e il valore del loro utilizzo per upgrade (e rollback) sicuri del mesh di servizio.

Nozioni di base sull'installazione di Service Mesh

A livello generale, l'installazione di Cloud Service Mesh è costituita da due fasi principali:

1. Per prima cosa, utilizza lo strumento asmcli per installare un control plane in-cluster o configurare il control plane gestito. Il control plane è costituito da un insieme di servizi di sistema responsabili della gestione della configurazione del mesh.

2. Successivamente, esegui il deployment di un proxy sidecar speciale in tutto l'ambiente che intercetta le comunicazioni di rete da e verso ogni workload. I proxy comunicano con il control plane per ottenere la configurazione, il che ti consente di indirizzare e controllare il traffico (traffico del piano dati) nel mesh senza apportare modifiche ai workload.

   Per eseguire il deployment dei proxy, utilizza un processo chiamato inserimento automatico di sidecar per eseguire un proxy come container sidecar aggiuntivo in ciascuno dei pod del workload. Non occorre modificare i manifest Kubernetes che utilizzi per eseguire il deployment dei workload, ma devi aggiungere un'etichetta agli spazi dei nomi e riavviare i pod.

Utilizza le revisioni per eseguire l'upgrade del mesh in modo sicuro

La possibilità di controllare il traffico è uno dei principali vantaggi dell'utilizzo di un mesh di servizi. Ad esempio, puoi spostare gradualmente il traffico verso una nuova versione di un'applicazione quando la implementi per la prima volta in produzione. Se rilevi problemi durante l'upgrade, puoi reindirizzare il traffico alla versione originale, il che è un modo semplice e a basso rischio per eseguire il rollback. Questa procedura è nota come versione canary e riduce notevolmente il rischio associato ai nuovi deployment.

Nota: un tipo alternativo di upgrade è quello in loco, ovvero quando l'upgrade viene eseguito installando una nuova versione del control plane che sostituisce immediatamente la versione precedente. Gli upgrade in loco sono rischiosi perché, in caso di errori, il rollback può essere difficile. Per reinserire i proxy e farli comunicare con la nuova versione del control plane, devi riavviare tutti i workload in tutti gli spazi dei nomi. A seconda del numero di workload e spazi dei nomi nel mesh, l'intero processo di upgrade potrebbe richiedere un'ora o più. Gli upgrade in loco possono comportare tempi di inattività e devono essere pianificati nei periodi di manutenzione.

Se utilizzi le revisioni del control plane in un upgrade canary, installa un nuovo control plane e una nuova configurazione separati, insieme al control plane esistente. Il programma di installazione assegna una stringa (chiamata revisione) per identificare il nuovo control plane. All'inizio, i proxy sidecar continuano a ricevere la configurazione dalla versione precedente del control plane. Associa gradualmente i workload al nuovo control plane etichettando i relativi spazi dei nomi o pod con la nuova revisione del control plane. Dopo aver etichettato uno spazio dei nomi o i pod con la nuova revisione, riavvia i pod del workload in modo che i nuovi sidecar vengano inseriti automaticamente e ricevano la configurazione dal nuovo control plane. In caso di problemi, puoi eseguire facilmente il rollback associando i workload al control plane originale.

Come funziona l'inserimento automatico?

L'inserimento automatico utilizza una funzionalità di Kubernetes chiamata controllo di ammissione. Un webhook di ammissione mutante è registrato per monitorare i pod appena creati. Il webhook è configurato con un selettore dello spazio dei nomi in modo che corrisponda solo ai pod di cui viene eseguito il deployment negli spazi dei nomi con un'etichetta specifica. Quando un pod corrisponde, il webhook consulta un servizio di inserimento fornito dal control plane per ottenere una nuova configurazione modificata per il pod, che contiene i container e i volumi necessari per eseguire il sidecar.

1. Durante l'installazione viene creata una configurazione webhook. Il webhook è registrato con il server dell'API Kubernetes.
2. Il server API Kubernetes monitora i deployment dei pod negli spazi dei nomi che corrispondono al webhook namespaceSelector.
3. Uno spazio dei nomi viene etichettato in modo che corrisponda a namespaceSelector.
4. I pod di cui è stato eseguito il deployment nello spazio dei nomi attivano il webhook.
5. Il servizio inject fornito dal control plane modifica le specifiche del pod per inserire automaticamente il sidecar.

Che cos'è una revisione?

L'etichetta utilizzata per l'iniezione automatica è come qualsiasi altra etichetta Kubernetes definita dall'utente. Un'etichetta è essenzialmente una coppia chiave-valore che può essere utilizzata per supportare il concetto di etichettatura. Le etichette sono ampiamente utilizzate per il tagging e per le revisioni. Ad esempio, tag Git, tag Docker e revisioni Knative.

L'attuale procedura di installazione di Cloud Service Mesh consente di etichettare il control plane installato con una stringa di revisione. Il programma di installazione etichetta ogni oggetto del control plane con la revisione. La chiave nella coppia chiave-valore è istio.io/rev, ma il valore dell'etichetta di revisione è diverso per il control plane gestito e per i control plane in-cluster.

• Per i control plane in-cluster, il servizio e il deployment istiod in genere hanno un'etichetta di revisione simile a istio.io/rev=asm-11910-9, dove asm-11910-9 identifica la versione di Cloud Service Mesh. La revisione diventa parte del nome del servizio, ad esempio: istiod-asm-11910-9.istio-system

• Per il control plane gestito, l'etichetta di revisione corrisponde a un canale di rilascio:

  Etichetta di revisione	Canale
  istio.io/rev=asm-managed	Regolare
  istio.io/rev=asm-managed-rapid	Rapido
  istio.io/rev=asm-managed-stable	Stabile

Inoltre, puoi utilizzare etichette di inserimento predefinite (ad esempio, istio-injection=enabled).

Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione agli spazi dei nomi e che corrisponda all'etichetta di revisione nel control plane. Ad esempio, un control plane con revisione istio.io/rev=asm-11910-9 seleziona i pod negli spazi dei nomi con l'etichetta istio.io/rev=asm-11910-9 e inserisce i sidecar.

Processo di upgrade canary

Le etichette di revisione consentono di eseguire upgrade canary e rollback semplici del control plane in-cluster. Il controllo gestito utilizza un processo simile, ma il cluster viene aggiornato automaticamente all'ultima versione all'interno di questo canale.

I passaggi seguenti descrivono la procedura:

1. Inizia con un'installazione esistente di Cloud Service Mesh o Istio open source. Non importa se gli spazi dei nomi utilizzano un'etichetta di revisione o l'etichetta istio-injection=enabled.
2. Utilizza una stringa di revisione quando installi la nuova versione del control plane. A causa della stringa di revisione, il nuovo control plane viene installato insieme alla versione esistente. La nuova installazione include una nuova configurazione webhook con un namespaceSelector configurato per monitorare gli spazi dei nomi con quell'etichetta di revisione specifica.
3. Esegui la migrazione dei proxy sidecar al nuovo control plane rimuovendo la vecchia etichetta dallo spazio dei nomi, aggiungendo la nuova etichetta di revisione e riavviando i pod. Se utilizzi le revisioni con Cloud Service Mesh, devi interrompere l'utilizzo dell'etichetta istio-injection=enabled. Un control plane con una revisione non seleziona i pod negli spazi dei nomi con un'etichetta istio-injection, anche se è presente un'etichetta di revisione. Il webhook per il nuovo control plane inserisce i sidecar nei pod.
4. Testa attentamente i workload associati al control plane di cui è stato eseguito l'upgrade e continua a implementare l'upgrade oppure esegui il rollback al control plane originale.

Dopo aver associato i pod al nuovo control plane, il control plane e il webhook esistenti sono ancora installati. Il webhook precedente non ha effetto sui pod negli spazi dei nomi di cui è stata eseguita la migrazione al nuovo control plane. Per eseguire il rollback al control plane originale dei pod in uno spazio dei nomi, rimuovi la nuova etichetta di revisione, aggiungi nuovamente l'etichetta originale e riavvia i pod. Quando hai la certezza che l'upgrade sia completato, puoi rimuovere il control plane precedente.

Per la procedura dettagliata per l'upgrade utilizzando le revisioni, consulta la guida all'upgrade.

Analisi dettagliata della configurazione di un webhook mutante

Per comprendere meglio il webhook di mutazione per l'inserimento automatico di sidecar, esamina tu stesso la configurazione. Utilizza il seguente comando:

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

Dovresti visualizzare una configurazione separata per ogni control plane che hai installato. Un selettore dello spazio dei nomi per un control plane basato sulla revisione ha il seguente aspetto:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-11910-9

Il selettore può variare a seconda della versione di Cloud Service Mesh o Istio in esecuzione. Questo selettore corrisponde agli spazi dei nomi con un'etichetta di revisione specifica, a condizione che non abbiano anche un'etichetta istio-injection.

Quando un pod viene distribuito in uno spazio dei nomi corrispondente al selettore, la relativa specifica viene inviata al servizio di inserimento per la mutazione. Il servizio di inserimento da chiamare è specificato come segue:

     service:
        name: istiod-asm-11910-9
        namespace: istio-system
        path: /inject
        port: 443

Nota: per Cloud Service Mesh gestito, il servizio gestito da Google è specificato da url: anziché da service:.

Il servizio è esposto dal control plane sulla porta 443 nel percorso URL inject.

La sezione rules specifica che il webhook deve essere applicato alla creazione del pod:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

Passaggi successivi

• Esegui l'upgrade di Cloud Service Mesh
• Inserimento di proxy sidecar