Revisioni del piano di controllo di Cloud Service Mesh

Questa pagina descrive il funzionamento delle revisioni del piano di controllo e il valore del loro utilizzo per gli upgrade (e i rollback) sicuri di mesh di servizi.

Nozioni di base sull'installazione del mesh di servizi

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

1. Innanzitutto, utilizza lo strumento asmcli per installare un piano di controllo all'interno del cluster o per configurare il piano di controllo gestito. Il piano di controllo è 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 nell'intero ambiente che intercetta la comunicazione di rete verso e da ciascun carico di lavoro. I proxy dialogano con il piano di controllo per ottenere la loro configurazione, il che ti consente di indirizzare e controllare il traffico (traffico del piano dati) all'interno del tuo mesh senza apportare modifiche ai carichi di lavoro.

   Per eseguire il deployment dei proxy, utilizzi un processo chiamato iniezione automatica di sidecar (iniezione automatica) per eseguire un proxy come contenitore sidecar aggiuntivo in ciascuno dei tuoi pod di workload. Non devi modificare i manifest Kubernetes che utilizzi per eseguire il deployment dei tuoi workload, ma devi aggiungere un'etichetta ai tuoi spazi dei nomi e riavviare i pod.

Utilizzare le revisioni per eseguire l'upgrade della mesh in sicurezza

La possibilità 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 la esegui per la prima volta in produzione. Se rilevi problemi durante l'upgrade, puoi spostare il traffico sulla versione originale, offrendo un modo semplice e a basso rischio per eseguire il rollback. Questa procedura è nota come release canary e riduce notevolmente il rischio associato ai nuovi deployment.

Nota: un tipo alternativo di upgrade è l'upgrade in situ, in cui esegui l'upgrade installando una nuova versione del piano di controllo. La nuova versione del piano di controllo sostituisce immediatamente la precedente. Gli upgrade in situ sono rischiosi perché, in caso di errori, il rollback può essere difficile. Per reinserire i proxy e farli comunicare 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 workload e spazi dei nomi nel mesh, l'intero processo di upgrade potrebbe richiedere un'ora o più. Gli upgrade in situ possono comportare tempi di inattività e devono essere pianificati nelle finestre di manutenzione.

Se utilizzi le revisioni del piano di controllo in un upgrade canary, installi un piano di controllo e una configurazione nuovi e distinti insieme al piano di controllo esistente. Il programma di installazione assegna una stringa chiamata 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 i relativi spazi dei nomi o pod con la revisione del nuovo piano di controllo. Dopo aver etichettato uno spazio dei nomi o i pod con la nuova revisione, riavvia i pod del carico di lavoro in modo che i nuovi sidecar vengano iniettati automaticamente e ricevano la configurazione dal nuovo control plane. In caso di problemi, puoi eseguire facilmente il rollback associando i carichi di lavoro al control plane originale.

Come funziona l'iniezione automatica?

L'iniezione automatica utilizza una funzionalità di Kubernetes chiamata controllo dell'accesso. È registrato un webhook di ammissione con mutazioni per monitorare i pod appena creati. Il webhook è configurato con un selettore dello spazio dei nomi in modo da corrispondere solo ai pod che vengono di cui viene eseguito il deployment in spazi dei nomi con un'etichetta specifica. Quando un pod corrisponde, il webhook consulta un servizio di inserimento fornito dal piano di controllo per ottenere una nuova configurazione mutata 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 API Kubernetes.
2. Il server API Kubernetes monitora i deployment dei pod negli spazi dei nomi corrispondenti all'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 piano di controllo modifica le specifiche del pod per iniettare 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 ti consente di etichettare il piano di controllo installato con una stringa di revisione. Il programma di installazione etichetta ogni oggetto del piano di controllo con la revisione. La chiave nella coppia chiave-valore è istio.io/rev, ma il valore dell'etichetta di revisione è diverso per il piano di controllo gestito e per i piani di controllo all'interno del cluster.

• Per i piani di controllo in cluster, il servizio e il deployment istiod hanno in genere un'etichetta di revisione simile a istio.io/rev=asm-1187-26, dove asm-1187-26 identifica la versione di Cloud Service Mesh. La revisione viene incorporata nel nome del servizio, ad esempio: istiod-asm-1187-26.istio-system

• Per il piano di controllo gestito, 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

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

Per attivare l'iniezione automatica, aggiungi agli spazi dei nomi un'etichetta di revisione corrispondente a quella del piano di controllo. Ad esempio, un piano di controllo con revisione istio.io/rev=asm-1187-26 seleziona i pod negli spazi dei nomi con l'etichetta istio.io/rev=asm-1187-26 e inietta i sidecar.

Procedura di upgrade canary

Le etichette di revisione consentono di eseguire upgrade canary e rollback facili del piano di controllo in-cluster. Il controllo gestito utilizza un processo simile, ma il cluster viene sottoposto automaticamente all'upgrade alla versione più recente all'interno del canale.

I passaggi seguenti descrivono il funzionamento della procedura:

1. Inizia con un'installazione di Cloud Service Mesh o Istio open source esistente. 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 piano di controllo. A causa della stringa di revisione, il nuovo control plane viene installato insieme alla versione esistente. La nuova installazione include una nuova configurazione del webhook con un namespaceSelector configurato per monitorare gli spazi dei nomi con l'etichetta di revisione specifica.
3. Esegui 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 riavviare i pod. Se utilizzi le revisioni con Cloud Service Mesh, devi interrompere l'utilizzo 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 è presente un'etichetta di revisione. Il webhook per il nuovo piano di controllo inietta i sidecar nei pod.
4. Testa attentamente i workload associati al piano di controllo di cui è stato eseguito l'upgrade e continua a implementare l'upgrade o esegui il rollback al piano di controllo originale.

Dopo aver associato i pod al nuovo piano di controllo, il piano di controllo e l'webhook esistenti sono ancora installati. Il vecchio webhook non ha alcun effetto sui pod nei nomespazi di cui è stata eseguita la migrazione al nuovo piano di controllo. Puoi eseguire il rollback degli elementi 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 vecchio ambito di controllo.

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

Un'occhiata più da vicino a una configurazione webhook con mutazioni

Per comprendere meglio il webhook con mutazioni per l'iniezione automatica del sidecar, esamina personalmente la configurazione. Utilizza il seguente comando:

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

Dovresti vedere una configurazione separata per ogni piano di controllo installato. Un selettore di spazi dei nomi per un piano di controllo basato su revisione è simile a questo:

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

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 sua specifica viene inviata al servizio di iniettore per la mutazione. Il servizio di inserimento da chiamare è specificato come segue:

     service:
        name: istiod-asm-1187-26
        namespace: istio-system
        path: /inject
        port: 443

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

Il servizio viene esposto dal piano di controllo sulla porta 443 nel percorso dell'URL inject.

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

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

Passaggi successivi

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