Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Sidecar-Proxys mit Cloud Service Mesh einfügen
In diesem Dokument wird beschrieben, wie Sie die Sidecar-Proxy-Injektion mit Cloud Service Mesh konfigurieren, um die Netzwerksicherheit, Zuverlässigkeit und Beobachtbarkeit zu verbessern. Diese Funktionen werden vom primären Container der Anwendung abstrahiert und in einem gemeinsamen Out-of-Process-Proxy (Sidecar) implementiert. Dieser wird als separater Container im selben Pod bereitgestellt. Dadurch werden die Features von Cloud Service Mesh bereitgestellt, ohne dass Ihre Produktionsanwendungen neu gestaltet werden müssen, um an einem Service Mesh teilzunehmen.
Die automatische Sidecar-Proxy-Einfügung (automatische Einfügung) tritt auf, wenn Cloud Service Mesh ein Namespace-Label erkennt, das Sie für den Pod der Arbeitslast konfigurieren. Der Proxy fängt den gesamten eingehenden und ausgehenden Traffic an die Arbeitslasten ab und kommuniziert mit Cloud Service Mesh.
Für diese Aufgaben erforderliche Berechtigungen
Zum Ausführen der Aufgaben auf dieser Seite benötigen Sie die Rolle roles/container.clusterAdmin oder eine höhere Rolle. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie unter Google Kubernetes Engine-Rollen.
Automatische Sidecar-Einfügung aktivieren
Die empfohlene Methode zum Einfügen der Sidecar-Proxys ist die Verwendung des Webhook-basierten automatischen Sidecar-Injektors. Sie können die Kubernetes-Konfiguration Ihrer Pods aber auch manuell aktualisieren.
Um die automatische Einfügung zu aktivieren, versehen Sie Ihre Namespaces mit den Standard-Injektionslabels, wenn das Standard-Tag eingerichtet ist, oder Sie wenden das Überarbeitungslabel auf Ihren Namespace an.
Das Label, das Sie hinzufügen, hängt auch davon ab, ob Sie das verwaltete Cloud Service Mesh (mit der Fleet API oder mit asmcli) bereitgestellt oder die clusterinterne Steuerungsebene installiert haben. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten Überarbeitung der Steuerungsebene zu verknüpfen.
So aktivieren Sie die automatische Einfügung:
Clusterintern
Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:
kubectl -n istio-system get pods -l app=istiod --show-labels
Notieren Sie sich den Wert des Überarbeitungslabels istiod aus der Ausgabe in der Spalte LABELS, das auf das Präfix istio.io/rev= folgt. In diesem Beispiel ist der Wert asm-1260-11.
Wenden Sie das Überarbeitungslabel auf Namespaces an und entfernen Sie das Label zur Istio-Einfügung (falls vorhanden). Im folgenden Befehl ist NAMESPACE der Name des Namespace, in dem Sie die automatische Einfügung aktivieren möchten. REVISION ist das Überarbeitungslabel, das Sie im vorherigen Schritt notiert haben.
Sie können die Nachricht "istio-injection not found" in der Ausgabe ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte, was bei Neuinstallationen von Cloud Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da das Verhalten bei der automatischen Injektion nicht definiert ist, wenn ein Namespace sowohl das istio-injection- als auch das Überarbeitungslabel hat, wird bei allen kubectl label-Befehlen in der Cloud Service Mesh-Dokumentation explizit darauf geachtet, dass nur eines festgelegt ist.
Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.
Verwaltetes Dienst-Mesh
Verwenden Sie folgenden Befehl, um die verfügbaren Release-Kanäle zu finden:
kubectl -n istio-system get controlplanerevision
Die Ausgabe sieht etwa so aus:
NAME AGE
asm-managed 6d7h
In der Ausgabe ist der Wert in der NAME-Spalte das REVISION-Label, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht. Wenden Sie dieses Label auf Ihre Namespaces an und entfernen Sie das Label istio-injection, sofern vorhanden.
Ersetzen Sie im folgenden Befehl REVISION durch das oben notierte Überarbeitungslabel und ersetzen Sie NAMESPACE durch den Namen des Namespace, in dem Sie die automatische Einfügung aktivieren möchten:
Sie können die Nachricht "istio-injection not found" in der Ausgabe ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte, was bei Neuinstallationen von Cloud Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da das Verhalten bei der automatischen Injektion nicht definiert ist, wenn ein Namespace sowohl das istio-injection- als auch das Überarbeitungslabel hat, wird bei allen kubectl label-Befehlen in der Cloud Service Mesh-Dokumentation explizit darauf geachtet, dass nur eines festgelegt ist.
Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.
Wenn Sie keine Bereitstellung verwendet haben, löschen Sie die Pods, und sie werden automatisch mit Sidecar-Dateien neu erstellt:
kubectl delete pod -n YOUR_NAMESPACE --all
Prüfen Sie, ob alle Pods im Namespace Sidecar-Dateien eingefügt haben:
kubectl get pod -n YOUR_NAMESPACE
In der folgenden Beispielausgabe des vorherigen Befehls sehen Sie, dass die Spalte READY zwei Container für jede Ihrer Arbeitslasten enthält: den primären Container und den Container für den Sidecar-Proxy.
NAME READY STATUS RESTARTS AGE
YOUR_WORKLOAD 2/2 Running 0 20s
...
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-02 (UTC)."],[],[],null,["Inject sidecar proxies with Cloud Service Mesh\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.20/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\nPermissions 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\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.20/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/docs/managed/provision-managed-anthos-service-mesh) or with\n[`asmcli`](/service-mesh/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\nIn-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-1264-1-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1264-1,istio=istiod,pod-template-hash=5788d57586\n istiod-asm-1264-1-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1264-1,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-1264-1`.\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\nManaged 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/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/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\nRestart Pods to update sidecar proxies **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\nLearn more about:\n\n- [Cloud Service Mesh control plane revisions](/service-mesh/v1.20/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)"]]
