Revisioni del piano di controllo di Cloud Service Mesh

Questa pagina si applica all'oggetto ISTIOD in-cluster e gestito implementazioni del piano di controllo. Questa pagina non si applica all'implementazione del control plane di TRAFFIC_DIRECTOR, che è un control plane globale multi-tenant senza revisioni individuali.

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 Service Mesh.

Nozioni di base sull'installazione del mesh di servizi

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

  1. Innanzitutto, usa lo strumento asmcli per installare piano di controllo nel cluster o configurare piano di controllo gestito. Il piano di controllo è composto da un insieme di servizi di sistema responsabili per gestire la configurazione mesh.

  2. Successivamente, eseguirai il deployment di uno speciale proxy sidecar in tutto l'ambiente che intercetta le comunicazioni di rete da e verso ogni 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 del file collaterale (inserimento automatico) di eseguire un proxy come container collaterale aggiuntivo in ciascuno dei pod del carico di lavoro. Non è necessario modificare i manifest Kubernetes che utilizzi per il deployment dei carichi di lavoro, ma devi aggiungere un'etichetta e riavvia 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 a una nuova versione di un'applicazione quando ne esegui il primo deployment in produzione. Se rilevi problemi durante l'upgrade, puoi spostare il traffico sulla versione originale, offrendo un metodo di rollback semplice e a basso rischio. Questa procedura è nota come versione canary, che riduce notevolmente il rischio associato a nuove deployment di machine learning.

Se utilizzi le revisioni del piano di controllo in un upgrade canary, installi un piano di controllo e una configurazione nuovi e distinti insieme a quello esistente. Il programma di installazione assegna una stringa denominata revisione per identificare il nuovo controllo aereo. Inizialmente, i proxy sidecar continuano a ricevere la configurazione all'ultima versione 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 il nuovo revisione, riavvia i pod del carico di lavoro in modo che i nuovi file collaterali vengano inseriti automaticamente e ricevono la configurazione dal nuovo piano di controllo. In caso di problemi, puoi eseguire facilmente il rollback associando i carichi di lavoro al piano di controllo originale.

Come funziona l'inserimento automatico?

L'inserimento automatico utilizza una funzionalità Kubernetes chiamata controllo di ammissione. È registrato un webhook di ammissione con mutazioni per monitorare i pod appena creati. La webhook è configurato con un selettore dello spazio dei nomi in modo che corrisponda solo ai pod il deployment in spazi dei nomi con una particolare etichetta. 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.

sidecar injector

  1. Durante l'installazione viene creata una configurazione webhook. Il webhook è registrato con il server API Kubernetes.
  2. Il server API Kubernetes controlla i deployment dei pod negli spazi dei nomi che corrisponde al webhook namespaceSelector.
  3. Uno spazio dei nomi è etichettato in modo che venga trovato dal 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 muta il pod specifiche per inserire automaticamente il file collaterale.

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 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 in 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-1232-2, dove asm-1232-2 identifica la versione di Cloud Service Mesh. La revisione viene incorporata nel nome del servizio, ad esempio: istiod-asm-1232-2.istio-system

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

    Etichetta di 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 abilitare l'inserimento automatico, aggiungi un'etichetta di revisione agli spazi dei nomi che corrisponde all'etichetta di revisione sul piano di controllo. Ad esempio, un piano di controllo con revisione istio.io/rev=asm-1232-2 seleziona i pod negli spazi dei nomi con l'etichetta istio.io/rev=asm-1232-2 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 una procedura simile, ma viene eseguito automaticamente l'upgrade del cluster alla versione più recente canale.

upgrade canary

I seguenti passaggi descrivono il funzionamento della procedura:

  1. Inizia con un Cloud Service Mesh o Istio open source esistente dell'installazione. 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. Per eseguire la migrazione dei proxy sidecar al nuovo piano di controllo, rimuovi il vecchio etichetta dello spazio dei nomi, aggiungendo la nuova etichetta di revisione al riavvio dei pod. Se utilizzi le revisioni con Cloud Service Mesh, non deve più usare l'etichetta istio-injection=enabled. Un piano di controllo con revisione non seleziona i pod negli spazi dei nomi con un attributo istio-injection anche se c'è un'etichetta di revisione. Il webhook per il nuovo piano di controllo inietta i sidecar nei pod.
  4. Testa attentamente i carichi di lavoro associati al piano di controllo sottoposto ad 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 per i pod in gli spazi dei nomi 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 sull'upgrade con 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 di sidecar, esamina personalmente la configurazione. Utilizza questo 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 dello spazio dei nomi per un piano di controllo basato su revisione ha il seguente aspetto: questo:

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

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

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

     service:
        name: istiod-asm-1232-2
        namespace: istio-system
        path: /inject
        port: 443

Il servizio è esposto dal piano di controllo sulla porta 443 all'URL inject del tuo percorso di apprendimento.

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