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äß den von Cloud Service Mesh empfangenen Anweisungen 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.
Nach ausgehendem IP-Adressbereich vom Abfangen ausschließen
Sie können festlegen, dass Traffic nach IP-Adressbereich nicht abgefangen wird.
... metadata: annotations: cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
Die Pod-Annotation cloud.google.com/excludeOutboundCIDRs
ist eine durch Kommas getrennte Liste ausgehender IP-Adressbereiche im CIDR-Format. Ausgehender Traffic für diese IP-Adressbereiche wird 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.
In das Abfangen durch ausgehenden IP-Adressbereich einschließen
Sie können abgefangenen Traffic nach IP-Adressbereich einschließen.
... metadata: annotations: cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
Die Pod-Annotation cloud.google.com/includeOutboundCIDRs
ist eine durch Kommas getrennte Liste ausgehender IP-Adressbereiche im CIDR-Format. Ausgehender Traffic für diese IP-Adressbereiche wird an die Envoy-Sidecar-Datei weitergeleitet.
Das Platzhalterzeichen *
kann verwendet werden, um den gesamten ausgehenden Traffic umzuleiten. Bei einer leeren Liste wird der gesamte ausgehende Traffic deaktiviert. Die Annotation ist standardmäßig *
.
Vom Abfangen nach ausgehender Portnummer ausschließen
Sie können Traffic anhand der Nummer des ausgehenden Ports ausschließen, sodass er abgefangen und weitergeleitet wird.
... metadata: annotations: cloud.google.com/excludeOutboundPorts: "10001, 10002"
Die Pod-Annotation cloud.google.com/excludeOutboundPorts
ist eine durch Kommas getrennte Liste ausgehender Ports. Ausgehender Traffic, der für diese Ports bestimmt ist, wird nicht abgefangen und an die Envoy-Sidecar-Datei weitergeleitet.
Wenn Sie die Annotation cloud.google.com/excludeOutboundPorts
nicht angeben, wird ausgehender Traffic für einen beliebigen Port abgefangen und an die Envoy-Sidecar-Datei weitergeleitet. Dies entspricht der Übergabe der Annotation cloud.google.com/excludeOutboundPorts
mit einer leeren Liste („“).
In das Abfangen nach Eingangsportnummer einbeziehen
Sie können abgefangenen Traffic über die Nummer des eingehenden Ports einbeziehen.
... metadata: annotations: cloud.google.com/includeInboundPorts: "10001, 10002"
Die Pod-Annotation cloud.google.com/includeInboundPorts
ist eine durch Kommas getrennte Liste von eingehenden Ports, für die Traffic an die Envoy-Sidecar-Datei weitergeleitet werden soll. Mit dem Platzhalterzeichen *
kann die Weiterleitung für alle Ports konfiguriert werden. Bei einem leeren Wert werden alle eingehenden Weiterleitungen deaktiviert. Die Standardeinstellung ist ein leerer String („“).
Vom Abfangen nach Nummer des eingehenden Ports ausschließen
Sie können Traffic über die Nummer des eingehenden Ports ausschließen, um ihn abzufangen.
... metadata: annotations: cloud.google.com/excludeInboundPorts: "10001, 10002"
Die Pod-Annotation cloud.google.com/excludeInboundPorts
ist eine durch Kommas getrennte Liste eingehender Ports, die von der Weiterleitung an die Envoy-Sidecar-Datei ausgeschlossen werden sollen. Die Anmerkung gilt nur, wenn der gesamte eingehende Traffic (*
) weitergeleitet wird. Der Wert 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-Annotation cloud.google.com/enableManagedCerts
auf true
gesetzt ist, werden vom Certificate Authority Service signierte Arbeitslastzertifikate eingefügt, die von GKE verwaltet und auf dem Sidecar-Container bereitgestellt werden. Der Wert der Annotation ist standardmäßig false
.
Sidecar-Proxy-Metadaten konfigurieren
Zur Unterstützung zusätzlicher Cloud Service Mesh-Features können Sidecar-Proxys bestimmte Metadaten von ihren kapselnden Pods übernehmen. Dafür gibt es zwei Möglichkeiten. Bei beiden Optionen werden Metadaten angehängt und sie werden für Cloud Service Mesh freigegeben, 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.
Durch das Filtern der Konfiguration kann Cloud Service Mesh dann einen Teil der Konfiguration nur mit den spezifischen Proxys teilen, 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-Injektion. Obwohl zusätzliche Sidecar-Injektor-Annotationen funktionieren könnten, enthält die folgende Liste Anmerkungen, 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 automatisch ein Envoy-Sidecar 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 sollen. |
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 der eingehenden Ports | Eine durch Kommas getrennte Liste von eingehenden Ports, für die Traffic an die Envoy-Sidecar-Datei weitergeleitet wird. Verwenden Sie das Platzhalterzeichen „*“, um die Weiterleitung für alle Ports zu konfigurieren. Bei einem leeren Wert werden alle eingehenden Weiterleitungen deaktiviert. Der Wert ist standardmäßig ein leerer String (""). |
cloud.google.com/excludeInboundPorts | Durch Kommas getrennte Liste der eingehenden Ports | Eine durch Kommas getrennte Liste von eingehenden Ports, für die kein Traffic an die Envoy-Sidecar-Datei weitergeleitet wird. Die Annotation gilt nur, wenn der gesamte eingehende Traffic (*) weitergeleitet wird. Der Wert ist standardmäßig 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 umgeht den Envoy-Proxy und wird nicht gemäß der Cloud Service Mesh-Konfiguration verarbeitet. 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. Die durch Kommas getrennte Liste darf keine Leerzeichen enthalten. |
cloud.google.com/includeOutboundCIDRs | Durch Kommas getrennte Liste ausgehender IP-Bereiche im CIDR-Format. | Ausgehender Traffic, der eine dieser Ziel-IP-Adressen angibt, ist beim Abfangen/Weiterleiten an die Envoy-Sidecar-Datei enthalten. Dieser Traffic wird an den Envoy-Proxy weitergeleitet und gemäß der Cloud Service Mesh-Konfiguration verarbeitet. Der Standardwert ist "169.254.169.254/32". Dies ist der Bereich, der für die Kommunikation mit dem Metadatenserver erforderlich ist. Dieser Bereich ist erforderlich. Wenn Sie die Annotation „includeOutboundCIDRs“ angeben, müssen Sie also neben allen anderen CIDRs auch „169.254.169.254/32“ angeben. Die durch Kommas getrennte Liste darf keine Leerzeichen enthalten. |
cloud.google.com/enableManagedCerts | Boolesch, als String dargestellt. Beispiel: "true " |
Wenn dieser Wert auf „true “ festgelegt ist, werden vom Certificate Authority Service signierte GKE-verwaltete Arbeitslastzertifikate eingefügt und im Sidecar-Container bereitgestellt. 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-