Questa pagina è stata tradotta dall'API Cloud Translation.

Inserisci proxy sidecar con Anthos Service Mesh

Questo documento illustra come configurare l'inserimento proxy proxy con Anthos Service Mesh 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 fuori processo comune (file collaterale), fornito come container separato nello stesso pod. In questo modo puoi usufruire delle funzionalità di Anthos Service Mesh senza dover riprogettare le tue applicazioni di produzione per partecipare a un mesh di servizi.

L'inserimento automatico del proxy sidecar (inserimento automatico) si verifica quando Anthos 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 nei carichi di lavoro e comunica con Anthos Service Mesh.

Autorizzazioni richieste per queste attività

Per eseguire le attività in questa pagina, devi avere roles/container.clusterAdmin o un ruolo di livello superiore. Consulta la pagina relativa ai ruoli di Google Kubernetes Engine per i dettagli sulle autorizzazioni incluse in questo ruolo.

Abilitazione iniezione automatica sidecar

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

Per abilitare l'inserimento automatico, etichetta i tuoi 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 da se hai eseguito il deployment di Kubernetes Service Mesh gestito o hai installato il piano di controllo in-cluster. L'etichetta viene utilizzata dal webhook dell'iniettore sidecar per associare le sidecar iniettate a una revisione specifica del piano di controllo.

Per attivare 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 ha il seguente aspetto:
```
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1134-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1134-4,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1134-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1134-4,istio=istiod,pod-template-hash=5788d57586
```
Nell'output, sotto la colonna LABELS, indica il valore dell'etichetta di revisione istiod, che segue il prefisso istio.io/rev=. In questo esempio, il valore è asm-1134-4.

Nota: puoi sostituire istio.io/rev con l'etichetta istio-injection=enabled se è configurato il tag predefinito. Verifica che il tag predefinito esista istioctl tag list eseguendo l'elemento istioctl di OUTPUT_DIR.
Applica l'etichetta di revisione agli spazi dei nomi e rimuovi l'etichetta di iniezione istio (se presente). Nel comando seguente, NAMESPACE è il nome dello spazio dei nomi in cui vuoi abilitare l'inserimento automatico, mentre REVISION è l'etichetta di revisione annotata 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 in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection, che dovrebbe essere prevista nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatico non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
Riavvia i pod interessati, utilizzando i passaggi descritti nella sezione successiva.

Mesh di servizi gestiti

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 che corrisponde al canale di rilascio disponibile per la versione Anthos Service Mesh. Applica questa etichetta agli spazi dei nomi e rimuovi l'etichetta istio-injection (se presente). Nel comando seguente, sostituisci REVISION con l'etichetta di revisione indicata sopra e NAMESPACE con il nome dello spazio dei nomi in cui vuoi abilitare l'inserimento automatico:
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Puoi ignorare il messaggio "istio-injection not found" nell'output. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection, che dovrebbe essere prevista nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatico non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
Riavvia i pod interessati, utilizzando i passaggi descritti nella sezione successiva.
Se hai anche eseguito il deployment del piano dati gestito 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 dei file collaterali, puoi aggiornare quelli collaterali per i pod esistenti con un riavvio del pod:

Il modo in cui riavviare i pod dipende se sono stati creati come parte di un deployment.

Se hai utilizzato un deployment, riavvialo, che riavvia tutti i pod con sidecar:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
Se non hai utilizzato un deployment, elimina i pod e vengono ricreati automaticamente con i file collaterali:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Verifica che per tutti i pod nello spazio dei nomi siano inseriti sidecar:
```
kubectl get pod -n YOUR_NAMESPACE
```
Nel seguente esempio di output del comando precedente, la colonna READY indica che sono presenti due container per ogni carico 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: