Anthos Service Mesh utilizza i proxy sidecar per migliorare la sicurezza, l'affidabilità e l'osservabilità della rete. Queste funzioni vengono astratte dal container principale dell'applicazione e implementate in un proxy out-of-process comune (il sidecar), distribuito come container separato nello stesso pod. Fornisce le funzionalità di Anthos Service Mesh senza riprogettare le applicazioni di produzione per partecipare a un mesh di servizi.
L'inserimento automatico del proxy sidecar (inserimento automatica) si verifica quando Anthos Service Mesh rileva un'etichetta dello spazio dei nomi che configuri per il pod del carico di lavoro. Il proxy intercetta tutto il traffico in entrata e in uscita verso i carichi di lavoro e comunica con Anthos Service Mesh.
Attivazione dell'inserimento automatico dei file collaterali
Il modo consigliato per inserire proxy sidecar è utilizzare l'iniettore automatico collaterale basato su webhook, anche se puoi aggiornare manualmente la configurazione Kubernetes dei pod. Per abilitare l'inserimento automatico, devi aggiungere un'etichetta di revisione allo spazio dei nomi. L'etichetta che aggiungi dipende dal fatto che tu abbia eseguito il deployment del piano di controllo gestito da Google di Anthos Service Mesh o che abbia installato il piano di controllo nel cluster. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i file collaterali inseriti a una determinata revisione del piano di controllo.
Per abilitare l'inserimento automatico:
Nel cluster
Utilizza il seguente comando per individuare l'etichetta di revisione su
istiod
:kubectl -n istio-system get pods -l app=istiod --show-labels
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-198-6-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586 istiod-asm-198-6-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
Nell'output, sotto la colonna
LABELS
, prendi nota del valore dell'etichetta di revisioneistiod
, che segue il prefissoistio.io/rev=
. In questo esempio, il valore èasm-198-6
.Applica l'etichetta di revisione agli spazi dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel seguente comando,
NAMESPACE
è il nome dello spazio dei nomi in cui vuoi abilitare l'inserimento automatico eREVISION
è l'etichetta di revisione che hai annotato nel passaggio precedente.kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
Puoi ignorare il messaggio
"istio-injection not found"
nell'output. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichettaistio-injection
, cosa che dovresti aspettarti nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichettaistio-injection
sia l'etichetta di revisione, tutti i comandikubectl label
nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichettaistio-injection
.Riavvia i pod interessati, seguendo i passaggi descritti nella sezione successiva.
Gestita da Google
Applica la seguente etichetta di revisione agli spazi dei nomi e rimuovi l'etichetta
istio-injection
(se esistente). Nel seguente comando, sostituisciNAMESPACE
con il nome dello spazio dei nomi in cui vuoi abilitare l'inserimento automatica:kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed --overwrite
Puoi ignorare il messaggio
"istio-injection not found"
nell'output. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichettaistio-injection
, cosa che dovresti aspettarti nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichettaistio-injection
sia l'etichetta di revisione, tutti i comandikubectl label
nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichettaistio-injection
.Riavvia i pod interessati, seguendo i passaggi descritti nella sezione successiva.
Riavvia i pod per aggiornare i proxy sidecar
Con l'inserimento automatico dei file collaterali, puoi aggiornare i file collaterali per i pod esistenti con un riavvio del pod:
La modalità di riavvio dei pod dipende dal fatto che siano stati creati nell'ambito di un deployment.
Se hai utilizzato un deployment, riavvialo, in modo da riavviare tutti i pod con i file collaterali:
kubectl rollout restart deployment -n YOUR_NAMESPACE
Se non hai utilizzato un deployment, elimina i pod, che vengono ricreati automaticamente con i file collaterali:
kubectl delete pod -n YOUR_NAMESPACE --all
Verifica che tutti i pod nello spazio dei nomi abbiano dei sidecar inseriti:
kubectl get pod -n YOUR_NAMESPACE
Nel seguente esempio di output del comando precedente, puoi notare che la colonna
READY
indica che esistono due container per ciascuno dei tuoi carichi di lavoro: il container principale e il container per il proxy sidecar.NAME READY STATUS RESTARTS AGE YOUR_WORKLOAD 2/2 Running 0 20s ...
Passaggi successivi
Scopri di più su: