Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Übersicht zu Cloud Service Mesh.

Diese Seite wurde von der Cloud Translation API übersetzt.

Optionen für die Einrichtung des Google Kubernetes Engine-Pods mit automatischer Envoy-Einfügung

Diese Anleitung enthält Informationen zu zusätzlichen Optionen und Aufgaben für den automatischen Envoy-Sidecar-Injektor.

Sidecar-Proxys vorhandenen Arbeitslasten hinzufügen

Nachdem Sie den Sidecar-Injektor in Ihren Clustern installiert haben, werden Sidecar-Proxys automatisch in neu erstellte Pods in aktivierten Namespaces eingefügt. Wenn Sie bereits Arbeitslasten ausgeführt haben, bevor Sie den Sidecar-Injektor aktivieren, müssen Sie die Arbeitslasten neu starten, damit sie eingefügt werden können.

Für Pods, die von Deployment-, DaemonSet- oder StatefulSet-Controllern verwaltet werden, können Sie Folgendes ausführen:

# Deployment
kubectl rollout restart deployment/DEPLOYMENT_NAME --namespace NAMESPACE

# DaemonSet
kubectl rollout restart daemonset/DAEMONSET_NAME --namespace NAMESPACE

# StatefulSet
kubectl rollout restart statefulset/STATEFULSET_NAME --namespace NAMESPACE

Wenn Sie keinen der oben genannten Controller zum Bereitstellen Ihrer Pods verwendet haben, müssen Sie die Pods einzeln löschen. Anschließend werden sie automatisch mit neuen Sidecar-Proxys neu erstellt.

kubectl delete pod POD_NAME -n NAMESPACE

Prüfen Sie, ob in jeden Ihrer Pods ein Sidecar-Proxy-Container eingefügt wurde:

kubectl get pods -n NAMESPACE

Für den oben erstellten busybox-Client sollten beispielsweise 2/2 Pods ausgeführt werden – einer für die busybox-Anwendung selbst und ein weiterer für den eingefügten Envoy-Sidecar-Proxy:

NAME                      READY   STATUS    RESTARTS   AGE
busybox-c54f578c9-c9fk4   2/2     Running   183        7d15h

Einfügungsüberschreibungen

Standardmäßig wird beim Aktivieren eines Namespace die Sidecar-Proxy-Einfügung für alle residenten Pods aktiviert. Die Einfügung kann auch gezielt für verschiedene Bereiche nach Bedarf konfiguriert werden. Zum Beispiel soll mit Überschreibungen verhindert werden, dass die Sidecar-Proxy-Einfügung für proxylose gRPC-Dienste verwendet wird.

Beachten Sie, dass die Einfügungsüberschreibungen nur angewendet werden, wenn der Namespace aktiviert ist, und mit der folgenden Priorität wirksam werden: Pod-Annotationen > NeeInjectSelector > AlwaysInjectSelector > Standardrichtlinie

Einfügung für bestimmte Pods aktivieren/deaktivieren

Verwenden Sie die folgende Pod-Annotation, um die Injektion für einen bestimmten Pod in einem aktivierten Namespace zu aktivieren bzw. zu deaktivieren:

...
metadata:
  annotations:
    sidecar.istio.io/inject: "true" / "false"

Einfügung für bestimmte Gruppen von Pods aktivieren/deaktivieren

Der Sidecar-Injektor kann so konfiguriert werden, dass Pods basierend auf einem Array von Kubernetes-Labelselektoren immer oder nie in aktivierte Namespaces eingefügt werden. Mit den folgenden Befehlen konfigurieren Sie beispielsweise den Sidecar-Injektor so, dass er einen Sidecar-Proxy nicht einfügt, wenn der Pod das Label "run=client" hat:

kubectl edit configmap -n istio-control istio-sidecar-injector

...
config: |-
  policy: enabled
  alwaysInjectSelector:
    []

  neverInjectSelector:
    - matchLabels:
        run: client
...

Vorhandene Sidecar-Injektor-Deployments müssen neu gestartet werden, damit diese Konfiguration wirksam wird.

Verhalten zum Abfangen von Traffic anpassen

Standardmäßig wird der gesamte ausgehende Traffic von Ihrer Anwendung abgefangen und an den Envoy-Sidecar-Proxy weitergeleitet. Der Envoy-Proxy kann dann den Traffic gemäß der von Cloud Service Mesh empfangenen Anleitung verarbeiten. In einigen Fällen kann es sinnvoll sein, dieses Verhalten zu ändern, um den Sidecar-Proxy zu umgehen.

Mit folgenden Pod-Annotationen können Sie Traffic von Abfangen und Weiterleitung ausschließen.

Vom Abfangen nach ausgehendem IP-Adressbereich ausschließen

Sie können Traffic nach IP-Adressbereich vom Abfangen ausschließen.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

Die cloud.google.com/excludeOutboundCIDRs-Pod-Anmerkung ist eine durch Kommas getrennte Liste ausgehender IP-Adressbereiche im CIDR-Format. Ausgehender Traffic für werden diese IP-Adressbereiche nicht an die Envoy-Sidecar-Datei weitergeleitet.

Beachten Sie, dass Sie 169.254.169.254/32 in der Pod-Annotation auflisten müssen, damit Anwendungen mit dem Metadatenserver kommunizieren können. Wenn Sie die Pod-Annotation cloud.google.com/excludeOutboundCIDRs nicht angeben, wird das Abfangen von Traffic so konfiguriert, dass der ausgehende CIDR-Bereich "169.254.169.254/32" ausgeschlossen ist.

Vom Abfangen nach ausgehendem IP-Adressbereich ausschließen

Sie können Traffic nach IP-Adressbereich in die Abfangung einbeziehen.

...
metadata:
  annotations:
    cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

Die cloud.google.com/includeOutboundCIDRs-Pod-Anmerkung ist eine durch Kommas getrennte Liste ausgehender IP-Adressbereiche im CIDR-Format. Ausgehender Traffic für werden diese IP-Adressbereiche an die Envoy-Sidecar-Datei weitergeleitet.

Mit dem Platzhalterzeichen * können Sie den gesamten ausgehenden Traffic umleiten. Bei einer leeren Liste wird der gesamte ausgehende Traffic deaktiviert. Die Standardeinstellung für die Annotation ist *.

Vom Abfangen nach ausgehender Portnummer ausschließen

Sie können Traffic nach ausgehender Portnummer vom Abfangen und Weiterleiten ausschließen.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundPorts: "10001, 10002"

Die cloud.google.com/excludeOutboundPorts-Pod-Anmerkung ist eine durch Kommas getrennte Liste von ausgehenden Ports. Der ausgehende Traffic für diese Ports ist vom Abfangen und vom Weiterleiten an den Envoy-Sidecar-Proxy ausgeschlossen.

Wenn Sie die Annotation cloud.google.com/excludeOutboundPorts nicht angeben, wird der für Ports bestimmte ausgehende Traffic abgefangen und an den Envoy-Sidecar-Proxy weitergeleitet. Dies entspricht dem Annotation cloud.google.com/excludeOutboundPorts mit einer leeren Liste („“).

In Abfangen nach Eingangsportnummer einbeziehen

Sie können Traffic nach eingehender Portnummer in die Abfangung einbeziehen.

...
metadata:
  annotations:
    cloud.google.com/includeInboundPorts: "10001, 10002"

Die Pod-Annotation cloud.google.com/includeInboundPorts ist eine durch Kommas getrennte Anmerkung Liste der eingehenden Ports, für die Traffic an Envoy weitergeleitet werden soll Sidecar-Datei. Mit dem Platzhalterzeichen * können Sie die Weiterleitung für alle Ports konfigurieren. Bei einem leeren Wert wird die gesamte eingehende Weiterleitung deaktiviert. Der Standardwert ist eine leere Zeichenfolge ("").

Vom Abfangen nach eingehender Portnummer ausschließen

Sie können Traffic anhand der Eingangsportnummer vom Abfangen ausschließen.

...
metadata:
  annotations:
    cloud.google.com/excludeInboundPorts: "10001, 10002"

Die Pod-Annotation cloud.google.com/excludeInboundPorts ist durch Kommas getrennt Liste der eingehenden Ports, die von der Weiterleitung an die Envoy-Sidecar-Datei ausgeschlossen werden sollen. Die Annotation gilt nur, wenn der gesamte eingehende Traffic (*) weitergeleitet wird. Die value ist standardmäßig ein leerer String ("").

Verwaltete Zertifikate aktivieren

Sie können verwaltete Arbeitslastzertifikate aktivieren.

...
metadata:
  annotations:
    cloud.google.com/enableManagedCerts: "true"

Wenn die Pod-Anmerkung cloud.google.com/enableManagedCerts auf true festgelegt ist, werden von GKE verwaltete Arbeitslastzertifikate, die vom CA Service signiert wurden, eingefügt und im Sidecar-Container bereitgestellt. Der Wert der Anmerkung ist standardmäßig false.

Sidecar-Proxy-Metadaten konfigurieren

Zur Unterstützung zusätzlicher Cloud Service Mesh-Features können Sidecar-Proxys bestimmte Metadaten aus ihren kapselnden Pods. Dafür gibt es zwei Möglichkeiten. Bei beiden Optionen werden Metadaten angehängt und die Metadaten werden mit Cloud Service Mesh geteilt, wenn der Sidecar-Proxy eine Verbindung zu Cloud Service Mesh herstellt. Die Optionen schließen sich gegenseitig aus.

Mit der ersten Option können Sie einzelne Metadaten-Schlüssel/Wert-Paare angeben. Nehmen Sie beispielsweise die folgende Annotation in Ihre Spezifikation der Pod-Vorlage auf, um das Label "version": "dev" auf die eingefügten Sidecar-Proxys anzuwenden.

...
metadata:
  annotations:
    cloud.google.com/proxyMetadata: '{"version": "dev"}'

Die zweite Option hängt alle Labels des Pods an den eingeschleusten Sidecar-Proxy des Pods an.

...
metadata:
  annotations:
    cloud.google.com/forwardPodLabels: "true"

Wenn Sie die Annotation cloud.google.com/forwardPodLabels nicht angeben, werden Pod-Labels nicht an den Sidecar-Proxy angehängt. Die Annotationen cloud.google.com/proxyMetadata und cloud.google.com/forwardPodLabels schließen sich gegenseitig aus. Wenn Sie beide festlegen, hat cloud.google.com/forwardPodLabels Priorität und cloud.google.com/proxyMetadata wird ignoriert.

Konfigurationsfilter ermöglicht es Cloud Service Mesh, eine Teilmenge der Konfiguration nur für die bestimmte Proxys, die mit diesem "version": "dev"-Label übereinstimmen.

Vorhandene Deployments müssen neu gestartet werden, damit diese Konfiguration wirksam wird.

Unterstützte Pod-Annotationen

Cloud Service Mesh unterstützt die folgenden Pod-Annotationen für die Sidecar-Einfügung. Obwohl weitere Sidecar-Injektor-Annotationen funktionieren können, enthält die folgende Liste Annotationen, die von Cloud Service Mesh unterstützt werden. Erstellen Sie keine Abhängigkeiten von anderen Annotationen in Ihrer Produktionsbereitstellung, um Fehler oder Instabilität zu vermeiden.

Annotationsname	Wert	Beschreibung
sidecar.istio.io/inject	Boolesch, als String dargestellt. Beispiel: "`true`"	Gibt an, ob ein Envoy-Sidecar automatisch in die Arbeitslast eingefügt werden soll.
cloud.google.com/proxyMetadata	JSON-Zuordnung von Schlüssel/Wert-Paaren. Beispiel: "`'{"version": "dev"}'`"	Gibt die Schlüssel/Wert-Paare in einer JSON-Zuordnung an, die an Envoy-Metadaten angehängt werden sollten.
cloud.google.com/forwardPodLabels	„true” oder „false”	Wenn diese Option auf "true" gesetzt ist, werden alle Pod-Labels an Envoy-Metadaten angehängt und die Annotation "cloud.google.com/proxyMetadata" wird ignoriert. Die Standardeinstellung ist "false".
cloud.google.com/excludeOutboundPorts	Durch Kommas getrennte Liste mit Ausgangs-Ports	Ausgehender Traffic, der einen dieser Zielports angibt, ist vom Abfangen und Weiterleiten an den Envoy-Sidecar-Proxy ausgeschlossen. Dieser Traffic umgeht den Envoy-Proxy und wird nicht gemäß der Cloud Service Mesh-Konfiguration verarbeitet. Die Standardeinstellung ist ein leerer String (d. h. „“).
cloud.google.com/includeInboundPorts	Durch Kommas getrennte Liste mit Eingangs-Ports	Eine durch Kommas getrennte Liste von Eingangsports, für die Traffic an den Envoy-Sidecar weitergeleitet wird. Verwenden Sie das Platzhalterzeichen „*“, um die Weiterleitung für alle Ports konfigurieren. Bei einem leeren Wert werden alle eingehende Weiterleitung verwenden. Der Standardwert ist ein leerer String („“).
cloud.google.com/excludeInboundPorts	Durch Kommas getrennte Liste eingehender Ports	Eine durch Kommas getrennte Liste von Eingangsports, für die Traffic nicht an den Envoy-Sidecar weitergeleitet wird. Die Anmerkung gilt nur, wenn der gesamte eingehende Traffic (*) umgeleitet wird. Der Standardwert ist ein leerer String („“).
cloud.google.com/excludeOutboundCIDRs	Durch Kommas getrennte Liste ausgehender IP-Bereiche im CIDR-Format.	Ausgehender Traffic, der eine dieser Ziel-IP-Adressen angibt, ist vom Abfangen und Weiterleiten an den Envoy-Sidecar-Proxy ausgeschlossen. Dieser Traffic den Envoy-Proxy umgehen und nicht gemäß Cloud Service Mesh verarbeitet werden. Konfiguration. Der Standardwert ist "169.254.169.254/32". Dies ist der Bereich, der für die Kommunikation mit dem Metadatenserver erforderlich ist. Beachten Sie, dass dieser Bereich erforderlich ist. Wenn Sie die Annotation "ExcludeOutboundCIDRs" angeben, muss neben allen anderen CIDRs auch "169.254.169.254/32" angegeben sein. Stellen Sie sicher, dass Die durch Kommas getrennte Liste enthält keine Leerzeichen.
cloud.google.com/includeOutboundCIDRs	Durch Kommas getrennte Liste ausgehender IP-Bereiche im CIDR-Format.	Ausgehender Traffic, der eine dieser Ziel-IP-Adressen angibt, wird abgefangen und an den Envoy-Sidecar-Proxy weitergeleitet. Dieser Traffic ist an den Envoy-Proxy weitergeleitet und gemäß Cloud Service Mesh verarbeitet Konfiguration. Der Standardwert ist "169.254.169.254/32". Dies ist der Bereich, der für die Kommunikation mit dem Metadatenserver erforderlich ist. Beachten Sie, dass dieser Bereich erforderlich ist. Wenn Sie die Annotation „includeOutboundCIDRs“ angeben, muss neben allen anderen CIDRs auch „169.254.169.254/32“ angegeben sein. Die durch Kommas getrennte Liste darf keine Leerzeichen enthalten.
cloud.google.com/enableManagedCerts	Boolesch, als String dargestellt. Beispiel: "`true`"	Wenn „`true`“ festgelegt ist, wird die GKE-Arbeitslast verwaltet Vom Certificate Authority Service signierte Zertifikate werden eingefügt und bereitgestellt. für den Sidecar-Container. Der Standardwert ist „`false`“.

Sidecar-Injektor deinstallieren

Deinstallieren Sie den Sidecar-Injektor mit den folgenden Befehlen:

kubectl delete -f specs/
kubectl label namespace default istio-injection-