Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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
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.
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.
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:
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:
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
...
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["# Inject sidecar proxies with Cloud Service Mesh\n==============================================\n\nThis document covers how to configure sidecar proxy injection with Cloud Service Mesh\nto enhance network security, reliability, and observability. These functions are\nabstracted away from the application's primary container and implemented in a\ncommon out-of-process proxy (the sidecar), delivered as a separate container in\nthe same Pod. This provides the\n[Cloud Service Mesh's features](/service-mesh/v1.19/docs/overview) without redesigning your\nproduction applications to participate in a service mesh.\n\nAutomatic sidecar proxy injection (auto-injection) occurs when Cloud Service Mesh\ndetects a namespace label you configure for the workload's Pod. The proxy\nintercepts all inbound and outbound traffic to the workloads and communicates\nwith Cloud Service Mesh.\n\n#### Permissions required for these tasks\n\n\nTo perform the tasks on this page, you must have the\n`roles/container.clusterAdmin` or a higher role. See\n[Google Kubernetes Engine roles](/iam/docs/understanding-roles#container) for\ndetails on the permissions included in this role.\n\nEnabling automatic sidecar injection\n------------------------------------\n\nThe recommended way to inject sidecar proxies is to use the webhooks-based\nautomatic sidecar injector, although you can manually update your Pods'\nKubernetes configuration.\n\nTo enable auto-injection, you label your namespaces with the\n*[default injection labels](https://istio.io/latest/docs/setup/upgrade/canary/#default-tag)*\nif the default tag is set up, or with the\n[revision label](/service-mesh/v1.19/docs/revisions-overview) to your namespace.\nThe label that you add also depends on whether you deployed\nmanaged Cloud Service Mesh (with the\n[fleet API](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh) or with\n[`asmcli`](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh-asmcli)), or\ninstalled the in-cluster control plane. The label is used by the sidecar\ninjector webhook to associate injected sidecars with a particular control plane\nrevision.\n\nTo enable auto-injection: \n\n### In-cluster\n\n1. Use the following command to locate the revision label on `istiod`:\n\n kubectl -n istio-system get pods -l app=istiod --show-labels\n\n The output looks similar to the following: \n\n ```bash\n NAME READY STATUS RESTARTS AGE LABELS\n 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\n 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\n ```\n\n In the output, under the `LABELS` column, note the value of the `istiod`\n revision label, which follows the prefix `istio.io/rev=`. In this\n example, the value is `asm-11910-9`.\n\n\n | **Note:** You can substitute `istio.io/rev` with the `istio-injection=enabled` label if the [default tag](https://istio.io/latest/docs/setup/upgrade/canary/#default-tag) is configured. Verify the default tag exists by running ` istioctl tag list` with the `istioctl` from \u003cvar translate=\"no\"\u003eOUTPUT_DIR\u003c/var\u003e.\n\n \u003cbr /\u003e\n\n2. Apply the revision label to namespaces and remove the istio-injection label\n (if it exists). In the following command, \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e is\n the name of the namespace where you want to enable auto-injection, and\n \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e is the revision label you noted in the\n previous step.\n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio-injection- istio.io/rev=\u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e --overwrite\n\n\n You can ignore the message `\"istio-injection not found\"` in the\n output. That means that the namespace didn't previously have the\n `istio-injection` label, which you should expect in new\n installations of Cloud Service Mesh or new deployments. Because auto-injection\n behavior is undefined when a namespace has both the `istio-injection`\n and the revision label, all `kubectl label` commands in the\n Cloud Service Mesh documentation explicitly ensure that only one is set.\n3. Restart the affected pods, using the steps in the next section.\n\n### Managed service mesh\n\n1. Use the following command to locate the available release channels:\n\n kubectl -n istio-system get controlplanerevision\n\n The output is similar to the following: \n\n NAME AGE\n asm-managed 6d7h\n\n In the output, select the value under the `NAME` column is the\n \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e label that corresponds to the available\n [release channel](/service-mesh/v1.19/docs/managed/select-a-release-channel#anthos_service_mesh_versions_per_channel)\n for the Cloud Service Mesh version. Apply this label to your namespaces, and\n remove the `istio-injection` label (if it exists).\n In the following command, replace \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e with the\n revision label you noted above, and replace\n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e` ` with the name of the namespace where you\n want to enable auto-injection: \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio-injection- istio.io/rev=\u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e --overwrite\n\n\n You can ignore the message `\"istio-injection not found\"` in the\n output. That means that the namespace didn't previously have the\n `istio-injection` label, which you should expect in new\n installations of Cloud Service Mesh or new deployments. Because auto-injection\n behavior is undefined when a namespace has both the `istio-injection`\n and the revision label, all `kubectl label` commands in the\n Cloud Service Mesh documentation explicitly ensure that only one is set.\n2. Restart the affected pods, using the steps in the next section.\n\n3. If you also deployed the optional\n [Google-managed data plane](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh#managed-data-plane),\n annotate the `demo` namespace as follows:\n\n kubectl annotate --overwrite namespace \u003cvar translate=\"no\"\u003eYOUR_NAMESPACE\u003c/var\u003e \\\n mesh.cloud.google.com/proxy='{\"managed\":\"true\"}'\n\n### Restart Pods to update sidecar proxies\n\n| **Warning:** Unless you have a load balancer or router setup for [blue-green deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html), make sure you test restarting Pods in a staging environment to verify that your services can handle any potential traffic interruption.\n\nWith automatic sidecar injection, you can update the sidecars for existing Pods\nwith a Pod restart:\n\nHow you restart Pods depends on if they were created as part of a\n[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).\n\n1. If you used a Deployment, restart the Deployment, which restarts all Pods\n with sidecars:\n\n ```\n kubectl rollout restart deployment -n YOUR_NAMESPACE\n ```\n\n If you didn't use a Deployment, delete the Pods, and they are automatically\n recreated with sidecars: \n\n ```\n kubectl delete pod -n YOUR_NAMESPACE --all\n ```\n2. Check that all the Pods in the namespace have sidecars injected:\n\n ```\n kubectl get pod -n YOUR_NAMESPACE\n ```\n\n In the following example output from the previous command, notice that the\n `READY` column indicates there are two containers for each of your\n workloads: the primary container and the container for the sidecar proxy. \n\n ```\n NAME READY STATUS RESTARTS AGE\n YOUR_WORKLOAD 2/2 Running 0 20s\n ...\n ```\n\nWhat's next\n-----------\n\nLearn more about:\n\n- [Cloud Service Mesh control plane revisions](/service-mesh/v1.19/docs/revisions-overview)\n- [Deploying workloads](/kubernetes-engine/docs/how-to/deploying-workloads-overview)\n- [Customizing injection](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#customizing-injection)"]]
