Revisioni del piano di controllo di Anthos Service Mesh

Questa pagina descrive il funzionamento delle revisioni del piano di controllo e l'importanza di utilizzarle per eseguire upgrade (e rollback) del mesh di servizi sicuri.

Concetti fondamentali dell'installazione del mesh di servizi

A livello generale, l'installazione di Anthos Service Mesh prevede due fasi principali:

1. Innanzitutto, utilizza lo strumento asmcli per installare un piano di controllo nel cluster o per configurare il piano di controllo gestito da Google. Il piano di controllo è costituito da un insieme di servizi di sistema responsabili della gestione della configurazione mesh.

2. Successivamente, eseguirai il deployment di un proxy Sidecar speciale in tutto l'ambiente che intercetta le comunicazioni di rete da e verso ogni carico di lavoro. I proxy comunicano con il piano di controllo per ottenere la loro configurazione, che ti consente di indirizzare e controllare il traffico (traffico del piano dati) attorno al tuo mesh senza apportare alcuna modifica ai carichi di lavoro.

   Per eseguire il deployment dei proxy, utilizza un processo chiamato inserimento automatico dei file collaterali (inserimento automatico) per eseguire un proxy come container collaterale aggiuntivo in ciascuno dei pod dei carichi di lavoro. Non è necessario modificare i manifest Kubernetes utilizzati per il deployment dei carichi di lavoro, ma devi aggiungere un'etichetta agli spazi dei nomi e riavviare i pod.

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

La capacità di controllare il traffico è uno dei principali vantaggi dell'utilizzo di un mesh di servizi. Ad esempio, puoi spostare gradualmente il traffico su una nuova versione di un'applicazione quando ne esegui il deployment in produzione. Se rilevi problemi durante l'upgrade, puoi riportare il traffico alla versione originale in modo semplice e a basso rischio di rollback. Questa procedura è nota come release canary e riduce notevolmente il rischio associato ai nuovi deployment.

Nota: un tipo alternativo di upgrade è un upgrade in loco, che può essere eseguito installando una nuova versione del piano di controllo. La nuova versione del piano di controllo sostituisce immediatamente quella precedente. Gli upgrade in loco sono rischiosi perché, in caso di errori, il rollback può essere difficile. Per reinserire i proxy e fare in modo che comunichino con la nuova versione del piano di controllo, devi riavviare tutti i carichi di lavoro in tutti gli spazi dei nomi. A seconda del numero di carichi di lavoro e spazi dei nomi nel tuo mesh, l'intero processo di upgrade potrebbe richiedere un'ora o più. Gli upgrade in loco possono causare tempi di inattività e devono essere pianificati nei periodi di manutenzione.

Utilizzando le revisioni del piano di controllo in un upgrade canary, devi installare un piano di controllo e una configurazione nuovi e separati insieme al piano di controllo esistente. Il programma di installazione assegna una stringa denominata revisione per identificare il nuovo piano di controllo. All'inizio, i proxy sidecar continuano a ricevere la configurazione dalla versione precedente del piano di controllo. Associa gradualmente i carichi di lavoro al nuovo piano di controllo etichettando gli spazi dei nomi con la nuova revisione del piano di controllo. Dopo aver etichettato uno spazio dei nomi con la nuova revisione, riavvia i pod dei carichi di lavoro in modo che i nuovi file collaterali vengano inseriti automaticamente e ricevano la configurazione dal nuovo piano di controllo. In caso di problemi, puoi facilmente eseguire il rollback associando i carichi di lavoro al piano di controllo originale.

Come funziona l'iniezione automatica?

L'inserimento automatico utilizza una funzionalità di Kubernetes chiamata controllo di ammissione. Viene registrato un webhook di ammissione mutante per controllare 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 in spazi dei nomi con una determinata etichetta. Quando un pod corrisponde, il webhook consulta un servizio di inserimento fornito dal piano di controllo 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 viene registrato con il server 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 è 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 piano di controllo modifica le specifiche del pod per inserire automaticamente il file collaterale.

Che cos'è una revisione?

L'etichetta utilizzata per l'inserimento automatico è come qualsiasi altra etichetta Kubernetes definita dall'utente. Un'etichetta è essenzialmente una coppia chiave-valore che può essere utilizzata a supporto del concetto di tagging. Le etichette sono ampiamente utilizzate per il tagging e per le revisioni. Alcuni esempi includono tag Git, tag Docker e revisioni Knative.

Fino alla versione 1.6.8 di Anthos Service Mesh, le procedure di installazione predefinite hanno stabilito una convenzione per la configurazione del selettore dello spazio dei nomi nel webhook in modo che utilizzi l'etichetta: istio-injection=enabled

L'attuale processo di installazione di Anthos Service Mesh consente di taggare il piano di controllo installato con una stringa di revisione. Il programma di installazione etichetta con la revisione ogni oggetto del piano di controllo. La chiave nella coppia chiave-valore è istio.io/rev, ma il valore dell'etichetta di revisione è diverso per il piano di controllo gestito da Google e per i piani di controllo 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-1129-3, dove asm-1129-3 identifica la versione di Anthos Service Mesh. La revisione diventa parte del nome del servizio, ad esempio: istiod-asm-1129-3.istio-system

• 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

Per abilitare l'inserimento automatico, aggiungi agli spazi dei nomi un'etichetta di revisione che corrisponda all'etichetta di revisione sul piano di controllo. Ad esempio, un piano di controllo con revisione istio.io/rev=asm-1129-3 seleziona i pod negli spazi dei nomi con l'etichetta istio.io/rev=asm-1129-3 e inserisce i file collaterali.

Il processo di upgrade canary

Le etichette di revisione consentono di eseguire upgrade canary e rollback semplici del piano di controllo nel cluster. Il controllo gestito da Google utilizza un processo simile, ma viene eseguito automaticamente l'upgrade del cluster alla versione più recente all'interno del canale.

I passaggi seguenti spiegano come funziona la procedura:

1. Inizia con un'installazione Anthos Service Mesh o Istio open source esistente. Non è importante 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 piano di controllo. A causa della stringa di revisione, il nuovo piano di controllo viene installato insieme alla versione esistente. La nuova installazione include una nuova configurazione di webhook con un namespaceSelector configurato per controllare gli spazi dei nomi con quella specifica etichetta di revisione.
3. Puoi eseguire la migrazione dei proxy sidecar al nuovo piano di controllo rimuovendo la vecchia etichetta dallo spazio dei nomi, aggiungendo la nuova etichetta di revisione e riavviando i pod. Se utilizzi le revisioni con Anthos Service Mesh, devi interrompere l'uso dell'etichetta istio-injection=enabled. Un piano di controllo con una revisione non seleziona i pod negli spazi dei nomi con un'etichetta istio-injection, anche se esiste un'etichetta di revisione. Il webhook per il nuovo piano di controllo inserisce file collaterali nei pod.
4. Testa attentamente i carichi di lavoro associati al piano di controllo aggiornato e continua a implementare l'upgrade o a eseguire il rollback al piano di controllo originale.

Dopo aver associato i pod al nuovo piano di controllo, il piano di controllo e il webhook esistenti rimangono installati. Il webhook precedente non ha alcun effetto per i pod negli spazi dei nomi di cui è stata eseguita la migrazione al nuovo piano di controllo. Puoi eseguire il rollback dei pod in uno spazio dei nomi al piano di controllo originale rimuovendo la nuova etichetta di revisione, aggiungendo di nuovo l'etichetta originale e riavviando i pod. Quando hai la certezza che l'upgrade sia stato completato, puoi rimuovere il piano di controllo precedente.

Per la procedura dettagliata sull'upgrade con le revisioni, consulta la Guida all'upgrade.

Uno sguardo ravvicinato a una configurazione di webhook mutante

Per comprendere meglio il webhook mutante per l'inserimento automatico dei sidecar, controlla la configurazione autonomamente. Utilizza il seguente comando:

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

Dovresti visualizzare una configurazione separata per ogni piano di controllo che hai installato. Un selettore dello spazio dei nomi per un piano di controllo basato su revisioni ha il seguente aspetto:

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

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

Quando viene eseguito il deployment di un pod in uno spazio dei nomi corrispondente al selettore, la specifica del pod viene inviata al servizio di injector per la mutazione. Il servizio iniettore da chiamare è specificato come segue:

     service:
        name: istiod-asm-173-6
        namespace: istio-system
        path: /inject
        port: 443

Il servizio è esposto dal piano di controllo 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 Anthos Service Mesh
• Inserimento di proxy sidecar