Inserisci proxy sidecar con Cloud Service Mesh

Questo documento spiega come configurare l'inserimento del proxy sidecar con Cloud Service Mesh per migliorare la sicurezza, l'affidabilità e l'osservabilità della rete. Queste funzioni sono astratti dal container principale dell'applicazione e implementato in un proxy out-of-process comune (il file collaterale), pubblicato come container separato all'interno dello stesso pod. Ciò fornisce funzionalità di Cloud Service Mesh senza riprogettare il tuo le applicazioni di produzione per partecipare a un mesh di servizi.

L'inserimento automatico proxy sidecar (inserimento automatico) avviene quando Cloud Service Mesh rileva un'etichetta dello spazio dei nomi configurata 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 Cloud Service Mesh.

Autorizzazioni richieste per queste attività

Per eseguire le attività in questa pagina, devi avere il roles/container.clusterAdmin o un ruolo superiore. Consulta Ruoli di Google Kubernetes Engine sulle autorizzazioni incluse in questo ruolo.

Attivazione dell'inserimento automatico di file collaterali

Il modo consigliato per inserire proxy sidecar è quello di utilizzare i proxy basati su webhook iniettore collaterale automatico, anche se puoi aggiornare manualmente i pod configurazione di Kubernetes.

Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con il etichette di inserimento predefinite se è stato impostato il tag predefinito o con il revisiona l'etichetta al tuo spazio dei nomi. L'etichetta aggiunta dipende anche dal fatto che tu abbia eseguito o meno il deployment Cloud Service Mesh gestito (con fleet API o con asmcli) oppure che ha installato il piano di controllo nel cluster. L'etichetta è utilizzata dal file collaterale Webhook di injector per associare i sidecar inseriti a un determinato piano di controllo revisione.

Per attivare l'inserimento automatico:

Nel cluster

1. Usa questo 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-11910-9-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-11910-9,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-11910-9-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-11910-9,istio=istiod,pod-template-hash=5788d57586

   Nell'output, sotto la colonna LABELS, prendi nota del valore del parametro istiod etichetta di revisione, che segue il prefisso istio.io/rev=. In questo Ad esempio, il valore è asm-11910-9.

   Nota: puoi sostituire istio.io/rev con il metodo istio-injection=enabled se tag predefinito è configurata. Verifica che il tag predefinito esista eseguendo istioctl tag list con istioctl di OUTPUT_DIR.

2. Applica l'etichetta di revisione agli spazi dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, NAMESPACE è il nome dello spazio dei nomi per cui vuoi abilitare l'inserimento automatico REVISION è l'etichetta di revisione che hai annotato in passaggio precedente.

   kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
   

   Puoi ignorare il messaggio "istio-injection not found" nel come output. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection, prevista nelle nuove di Cloud Service Mesh o di nuovi deployment. Poiché l'inserimento automatico il comportamento non è definito quando uno spazio dei nomi ha sia istio-injection e l'etichetta di revisione, tutti i comandi kubectl label nella La documentazione di Cloud Service Mesh assicura esplicitamente che ne sia impostata una sola.

3. Riavvia i pod interessati, seguendo i passaggi nella sezione successiva.

Mesh di servizi gestito

1. Usa il seguente comando per individuare i canali di rilascio disponibili:

   kubectl -n istio-system get controlplanerevision
   

   L'output è simile al seguente:

   NAME                AGE
   asm-managed         6d7h
   

   Nell'output, seleziona il valore nella colonna NAME che è REVISION che corrisponde all'etichetta disponibile canale di rilascio per la versione Cloud Service Mesh. Applica questa etichetta agli spazi dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, sostituisci REVISION con il l'etichetta di revisione annotata sopra e sostituisci NAMESPACE con il nome dello spazio dei nomi in cui vuoi attivare l'inserimento automatico:

   kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
   

   Puoi ignorare il messaggio "istio-injection not found" nel come output. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection, prevista nelle nuove di Cloud Service Mesh o di nuovi deployment. Poiché l'inserimento automatico il comportamento non è definito quando uno spazio dei nomi ha sia istio-injection e l'etichetta di revisione, tutti i comandi kubectl label nella La documentazione di Cloud Service Mesh assicura esplicitamente che ne sia impostata una sola.

2. Riavvia i pod interessati, seguendo i passaggi nella sezione successiva.

3. Se hai eseguito anche il deployment della Piano dati gestito da Google, annota lo spazio dei nomi demo come segue:

   kubectl annotate --overwrite namespace YOUR_NAMESPACE \
   mesh.cloud.google.com/proxy='{"managed":"true"}'
   

Riavvia i pod per aggiornare i proxy sidecar

Avviso: a meno che tu non abbia configurato un bilanciatore del carico o un router per deployment blu/verde, assicurati di testare il riavvio dei pod in un ambiente di gestione temporanea per verificare che in grado di gestire qualsiasi potenziale interruzione del traffico.

Con l'inserimento automatico di file collaterali, puoi aggiornare i file collaterali per i pod esistenti. con il riavvio di un pod:

Il modo in cui riavvii i pod dipende dal fatto che siano stati creati o meno Deployment.

1. Se hai utilizzato un deployment, riavvialo; in questo modo vengono riavviati tutti i pod. con file collaterali:

   kubectl rollout restart deployment -n YOUR_NAMESPACE

   Se non hai utilizzato un deployment, elimina i pod, che vengono ricreato con file collaterali:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Controlla che in tutti i pod nello spazio dei nomi siano stati inseriti file collaterali:

   kubectl get pod -n YOUR_NAMESPACE

   Nell'output di esempio seguente del comando precedente, nota che la macro 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:

• Revisioni del piano di controllo di Cloud Service Mesh
• Deployment dei carichi di lavoro
• Personalizzazione dell'inserimento