Inserire proxy sidecar con Cloud Service Mesh

Questo documento descrive 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 astratte dal container principale dell'applicazione e implementate in un proxy out-of-process comune (il sidecar), fornito come container separato nello stesso pod. In questo modo vengono fornite le funzionalità di Cloud Service Mesh senza riprogettare le applicazioni di produzione per partecipare a un mesh di servizi.

L'inserimento automatico del proxy sidecar (inserimento automatico) si verifica quando Cloud 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 Cloud Service Mesh.

Autorizzazioni richieste per queste attività

Per eseguire le attività in questa pagina, devi disporre del ruolo roles/container.clusterAdmin o di un ruolo superiore. Consulta la sezione Ruoli Google Kubernetes Engine per i dettagli sulle autorizzazioni incluse in questo ruolo.

Attivazione dell'inserimento automatico di sidecar

Il modo consigliato per inserire i proxy sidecar è utilizzare l'injector sidecar automatico basato su webhook, anche se puoi aggiornare manualmente la configurazione Kubernetes dei tuoi pod.

Per attivare l'inserimento automatico, etichetta gli spazi dei nomi con le etichette di inserimento predefinite se il tag predefinito è configurato o con l' etichetta di revisione allo spazio dei nomi. L'etichetta che aggiungi dipende anche dal fatto che tu abbia eseguito il deployment di Cloud Service Mesh gestito (con l'API fleet o con asmcli) o installato il control plane in-cluster. L'etichetta viene utilizzata dal webhook dell'iniettore sidecar per associare i sidecar inseriti a una revisione specifica del control plane.

Per attivare l'inserimento automatico:

In-cluster

Utilizza il seguente comando per individuare l'etichetta della 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, nella colonna LABELS, prendi nota del valore dell'etichetta di revisione istiod, che segue il prefisso istio.io/rev=. In questo esempio, il valore è asm-11910-9.

Nota:puoi sostituire istio.io/rev con l'etichetta istio-injection=enabled se il tag predefinito è configurato. Verifica che il tag predefinito esista eseguendo istioctl tag list con istioctl da OUTPUT_DIR.

Applica l'etichetta di revisione agli spazi dei nomi e rimuovi l'etichetta istio-injection (se esiste). Nel comando seguente, NAMESPACE è il nome dello spazio dei nomi in cui vuoi attivare l'iniezione automatica e REVISION è 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'etichetta istio-injection, che dovresti aspettarti nelle nuove installazioni di Cloud Service Mesh o nei nuovi deployment. Poiché il comportamento di inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne sia impostata solo una.
Riavvia i pod interessati seguendo i passaggi descritti nella sezione successiva.

Mesh di servizi gestito

Utilizza 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 corrisponde all'etichetta REVISION del canale di rilascio disponibile per la versione di Cloud Service Mesh. Applica questa etichetta ai tuoi spazi dei nomi e rimuovi l'etichetta istio-injection (se esiste). Nel comando seguente, sostituisci REVISION con l'etichetta della revisione annotata sopra e sostituisci NAMESPACE con il nome dello spazio dei nomi in cui vuoi attivare l'iniezione automatica:
```
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'etichetta istio-injection, che dovresti aspettarti nelle nuove installazioni di Cloud Service Mesh o nei nuovi deployment. Poiché il comportamento di inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne sia impostata solo una.
Riavvia i pod interessati seguendo i passaggi descritti nella sezione successiva.
Se hai anche eseguito il deployment del piano dati gestito da Google facoltativo, 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

Con l'inserimento automatico di sidecar, puoi aggiornare i sidecar 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 sidecar:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
Se non hai utilizzato un deployment, elimina i pod e questi vengono ricreati automaticamente con i sidecar:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Verifica che tutti i pod nello spazio dei nomi abbiano i sidecar inseriti:
```
kubectl get pod -n YOUR_NAMESPACE
```
Nell'output di esempio seguente del comando precedente, nota che la colonna READY indica che ci sono 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: