Revisioni del piano di controllo di Cloud Service Mesh
Questa pagina si applica alle ISTIOD
implementazioni del piano di controllo in-cluster e gestite.
Questa pagina non si applica all'implementazione del control plane di TRAFFIC_DIRECTOR
, che è un control plane globale multi-tenant senza revisioni individuali.
In questa pagina viene descritto il funzionamento delle revisioni del piano di controllo e il valore di usandole per gli upgrade (e i rollback) sicuri del mesh di servizi.
Concetti fondamentali dell'installazione di mesh di servizi
A livello generale, l'installazione di Cloud Service Mesh prevede due fasi principali:
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.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 di comunicare con il piano di controllo per conoscerne la configurazione, di indirizzare e controllare il traffico (traffico del piano dati) attorno al 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 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.
Utilizza le revisioni per eseguire l'upgrade del tuo mesh in modo sicuro
La possibilità di controllare il traffico è uno dei principali vantaggi dell'utilizzo di una 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 riportare il traffico alla versione originale offrendo un metodo semplice e a basso rischio per il rollback. Questa procedura è nota come release canary e riduce notevolmente il rischio associato ai nuovi deployment.
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. All'inizio, i proxy sidecar continuano a ricevere la configurazione dalla versione precedente del piano di controllo. Associa gradualmente i carichi di lavoro il nuovo piano di controllo, etichettando gli spazi dei nomi o i pod con il nuovo la revisione del piano d'azione. 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 piano di controllo. Se ci sono problemi, puoi facilmente eseguire il rollback associando i carichi di lavoro dal piano di controllo originale.
Come funziona l'inserimento automatico?
L'inserimento automatico utilizza una funzionalità Kubernetes chiamata controllo di ammissione. Viene registrato un webhook di ammissione mutante per osservare 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 il webhook consulta un servizio di iniezione fornito dal controllo per ottenere una nuova configurazione mutata per il pod, che contiene i container e i volumi necessari per eseguire il file collaterale.
- Durante l'installazione viene creata una configurazione webhook. Il webhook è registrato con il server API Kubernetes.
- Il server API Kubernetes monitora i deployment dei pod negli spazi dei nomi corrispondenti all'webhook
namespaceSelector
. - Uno spazio dei nomi viene etichettato in modo che corrisponda a
namespaceSelector
. - I pod di cui è stato eseguito il deployment nello spazio dei nomi attivano il webhook.
- 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 il concetto di etichettatura. Le etichette sono ampiamente utilizzate per il tagging e per le revisioni. Ad esempio, tag Git, tag Docker Revisioni Knative.
L'attuale procedura di installazione di Cloud Service Mesh ti consente di etichettare gli elementi installati
il piano di controllo con una stringa di revisione. Il programma di installazione etichetta ogni 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
nei piani di controllo nel cluster.
Per i piani di controllo in cluster, il servizio e il deployment
istiod
in genere hanno un'etichetta di revisione simile aistio.io/rev=asm-1225-1
, doveasm-1225-1
identifica la versione di Cloud Service Mesh. La revisione diventa parte del nome del servizio, ad esempio:istiod-asm-1225-1.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, hai la possibilità di utilizzare
etichette di inserimento predefinite
(ad es. 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 la revisione istio.io/rev=asm-1225-1
, seleziona i pod negli spazi dei nomi con
l'etichetta istio.io/rev=asm-1225-1
e inserisce i file collaterali.
Processo 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 seguenti passaggi descrivono il funzionamento della procedura:
- 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
. - 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 del webhook con un
namespaceSelector
configurato per monitorare gli spazi dei nomi con l'etichetta di revisione specifica. - 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,
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'etichettaistio-injection
, anche se è presente un'etichetta di revisione. Il webhook per il nuovo controllo inserisce i file collaterali nei pod. - Testa attentamente i carichi di lavoro associati al piano di controllo aggiornato e continuare a implementare l'upgrade o eseguire il rollback dal piano di controllo.
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 ai pod in uno spazio dei nomi al piano di controllo originale, rimuovendo il nuovo l'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.
Uno sguardo ravvicinato alla configurazione mutante di webhook
Per comprendere meglio il webhook mutante per l'inserimento automatico del file collaterale, e non puoi controllare 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 sulle revisioni è simile a questo:
namespaceSelector:
matchExpressions:
- key: istio-injection
operator: DoesNotExist
- key: istio.io/rev
operator: In
values:
- asm-1225-1
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
purché 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-1225-1
namespace: istio-system
path: /inject
port: 443
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: '*'