Anthos Service Mesh und Traffic Director sind jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Übersicht zum Cloud Service Mesh.

Diese Seite wurde von der Cloud Translation API übersetzt.

Optionen für die Einrichtung einer Compute Engine-VM mit automatischer Envoy-Bereitstellung

Dieser Leitfaden enthält Informationen zu zusätzlichen Optionen und Aufgaben für die automatisierte Bereitstellung von Envoy.

Zusätzliche Optionen zum Erstellen von Instanzvorlagen

Wenn Sie eine Instanzvorlage für die automatisierte Bereitstellung eines Envoy-Proxys erstellen, können Sie mit den folgenden Parametern einige Aspekte der Bereitstellung und des Verhaltens der Proxys definieren.

Parameter	Wert und Beschreibung	Erforderlich oder optional
`--service-proxy`	`enabled` Steuert, ob der Dienstproxy und Agent auf der VM installiert und konfiguriert sind.	Erforderlich, wenn der Dienstproxy automatisch bereitgestellt und konfiguriert werden soll. Wenn Sie diese Einstellung weglassen, wird der Dienstproxy nicht installiert oder konfiguriert.
`--service-proxy:serving-ports`	Eine durch Semikolons getrennte Liste von Ports. Die Ports, auf denen Ihre Anwendung/Arbeitslast bereitgestellt wird. Der Dienstproxy fängt eingehenden Traffic ab und leitet ihn dann an die angegebenen Bereitstellungsports auf localhost weiter.	Optional Wenn Sie dieses Flag weglassen, verarbeitet der Dienstproxy nur ausgehenden Traffic aus Ihrer Arbeitslast. Eingehender Traffic wird vom Dienstproxy nicht verarbeitet.
`--service-proxy:proxy-port`	Ein einzelner Port. Der Port, den der Dienstproxy überwacht. Die VM fängt den Traffic ab und leitet ihn zu diesem Port für die Verarbeitung durch den Dienstproxy weiter.	Optional. Wenn Sie dieses Flag weglassen, wird standardmäßig der Wert `15001` verwendet.
`--service-proxy:network`	Der Name eines gültigen VPC-Netzwerks. Das Google Cloud-VPC-Netzwerk, das von der Steuerungsebene des Dienstproxys verwendet wird, um eine dynamische Konfiguration für den Dienstproxy zu generieren.	Erforderlich, wenn sich die VM in mehreren Netzwerken befindet. Andernfalls ist dies optional. Wenn Sie dieses Flag weglassen, wird der Wert verwendet, der bei der Erstellung der VM-Instanzvorlage mit dem Parameter `--network` angegeben wird.
`--service-proxy:tracing`	`ON` oder `OFF` Ermöglicht dem Dienstproxy, verteilte Tracing-Informationen zu generieren. Wenn dieser Wert auf `ON` gesetzt ist, generiert die Steuerungsebene des Dienstproxys eine Konfiguration, die ein auf der Anfrage-ID beruhendes Tracing aktiviert. Weitere Informationen finden Sie in der Dokumentation zu `generate_request_id` für den Envoy-Proxy.	Optional. Wenn Sie dieses Flag weglassen, ist das Tracing nicht aktiviert.
`--service-proxy:access-log`	Der Dateipfad für Zugriffslogs, die von der Steuerungsebene an den Dienstproxy gesendet werden. Alle eingehenden und ausgehenden Anfragen werden in dieser Datei aufgezeichnet. Weitere Informationen finden Sie in der Dokumentation zum Dateizugriffslog für den Envoy-Proxy.	Optional. Es gibt keinen Standardwert. Wenn Sie den Dateipfad nicht angeben, werden die Logs nicht erstellt.
`--service-proxy:intercept-all-outbound-traffic` (Vorschau)	Ermöglicht das Abfangen des gesamten ausgehenden Traffics durch den Dienstproxy und leitet ihn dann an einen externen Host weiter. Verwenden Sie `gcloud beta` mit dieser Option.	Optional.
`--service-proxy:exclude-outbound-ip-ranges` (Vorschau)	Eine durch Semikolons (;) getrennte Liste der IP-Adressen oder CIDR-Bereiche, die in Anführungszeichen (") angegeben sind, die von der Weiterleitung ausgeschlossen werden sollen. Gilt nur, wenn das Flag `intercept-all-outbound-traffic` festgelegt ist. Verwenden Sie `gcloud beta` mit dieser Option. Beispiel: `exclude-outbound-ip-ranges="8.8.8.8;129.168.10.0/24"`	Optional.
`--service-proxy:exclude-outbound-port-ranges` (Vorschau)	Eine durch Semikolons getrennte Liste der Ports oder Portbereiche, die in Anführungszeichen angegeben sind (""), die von der Weiterleitung ausgeschlossen werden sollen. Gilt nur, wenn das Flag `intercept-all-outbound-traffic` festgelegt ist. Verwenden Sie `gcloud beta` mit dieser Option. Beispiel: `exclude-outbound-port-ranges="81;8080-8090"`	Optional.
`--service-proxy:scope` (Vorschau)	Die Option `scope` definiert eine logische Konfigurationsgrenze für die Ressource `Gateway`. Beim Start einer VM kommuniziert der Dienstproxy mit Cloud Service Mesh, um die Routinginformationen abzurufen, die den Routen entsprechen, die mit diesem Bereichsnamen an das Gateway angehängt sind. Wenn `scope` angegeben ist, wird der Netzwerkwert ignoriert. Sie können `scope`- und `mesh`-Werte nicht gleichzeitig angeben. Verwenden Sie `gcloud beta` mit dieser Option.	Optional.
`--service-proxy:mesh` (Vorschau)	Die Option `mesh` definiert eine logische Konfigurationsgrenze für eine `Mesh`-Ressource. Beim Start einer VM kommuniziert der Dienstproxy mit Cloud Service Mesh, um die Routinginformationen abzurufen, die den Routen entsprechen, die mit diesem Mesh-Namen an `Mesh` angehängt sind. Wenn `mesh` angegeben ist, wird der Netzwerkwert ignoriert. Sie können `scope`- und `mesh`-Werte nicht gleichzeitig angeben. Verwenden Sie `gcloud beta` mit dieser Option.	Optional.
`--service-proxy:project-number` (Vorschau)	Die Option `project-number` gibt das Projekt an, in dem die Ressourcen `Mesh` und `Gateway` erstellt werden. Wenn nicht angegeben, wird das Projekt verwendet, in dem die Instanz vorhanden ist. Dies gilt nur für die neuen Service Routing APIs.	Optional.
`--service-proxy-labels`	Schlüssel/Wert-Paare im Format `key=value`. Labels, die Sie auf Ihren Dienstproxy anwenden können. Diese spiegeln sich in den Bootstrap-Metadaten Ihres Envoy-Proxys wider. Die Labels können beliebige `key=value`-Paare sein, die Sie als Proxymetadaten festlegen möchten, beispielsweise für die Konfigurationsfilter. Sie können diese Flags für Anwendungs- und Versionslabels verwenden, z. B. `app=review` oder `version=canary`. Sie können sie aber auch zusammen verwenden.	Optional.

Mit dem folgenden gcloud-Befehl wird beispielsweise eine Instanzvorlage namens proxy-it erstellt. Auf Instanzen, die mithilfe dieser Vorlage erstellt werden, ist der Envoy-Proxy und der Dienstproxy-Agent installiert.

gcloud compute instance-templates create proxy-it \
    --service-proxy enabled

Im folgenden Beispiel heißt die Instanzvorlage proxy-it, der Envoy-Proxy und der Dienstproxy-Agent sind installiert, der Bereitstellungs- und der Proxyport sind festgelegt, Tracing ist aktiviert und ein Label ist definiert.

gcloud compute instance-templates create proxy-it \
  --service-proxy enabled,serving-ports=8080,proxy-port=15001,tracing=ON \
  --service-proxy-labels version=canary

Das folgende Diagramm veranschaulicht den Trafficfluss, wenn Sie den Bereitstellungsport als 8080 angeben. Eingehende TCP-Verbindungen an Port 8080 werden von iptables abgefangen und an den Envoy-Proxy weitergeleitet, der sie dann an die Anwendung auf Ihrer VM übergibt, die den TCP-Port 8080 überwacht. Außerdem gilt:

Alle ausgehenden Verbindungen zu den VIPs der in Cloud Service Mesh konfigurierten Dienste werden von iptables abgefangen, das netfilter konfiguriert. Über netfilter wird gewährleistet, dass der entsprechende Traffic, der den Netzwerkstack durchläuft, abgefangen und an den Envoy-Proxy weitergeleitet wird. Das Load-Balancing des Traffics erfolgt dann anhand der Konfiguration von Cloud Service Mesh.
Alle anderen eingehenden Verbindungen werden nicht von iptables abgefangen und direkt an Dienste auf der VM weitergegeben.
Alle Verbindungen zu externen Endpunkten werden ohne Abfangen direkt an externe IP-Adressen weitergeleitet.
Der gesamte UDP-Traffic wird direkt an das Ziel weitergeleitet, ohne von iptables abgefangen zu werden.

Dies wird im folgenden Diagramm veranschaulicht:

Trafficverteilung mit Cloud Service Mesh (zum Vergrößern klicken)

Die Trafficflüsse im Diagramm sehen so aus:

Eingehender Traffic mit Zielport 80, nicht abgefangen und direkt an den Dienst weitergeleitet, der den Port überwacht.
Eingehender Traffic mit Zielport 8080, abgefangen und an den Envoy-Listener-Port weitergeleitet.
Envoy leitet Traffic von (2) an Dienst 2 weiter, der den localhost-Port 8080 überwacht.
Ausgehender Traffic für die VIP und den Port der Cloud Service Mesh-Weiterleitungsregel, abgefangen und an den Envoy-Listener-Port weitergeleitet.
Envoy leitet Traffic von (4) an den Endpunkt des Back-Ends des Cloud Service Mesh-Ziel-Back-End-Dienstes weiter.
Ausgehender Traffic, der für eine Nicht-Cloud Service Mesh-VIP und -Port bestimmt ist, nicht abgefangen und direkt an einen externen Dienst weitergeleitet wird.

Labels verwenden

Wenn Sie Labels für die Verwendung mit der Cloud Service Mesh-Metadatenfilterung angeben oder das Zugriffs-Logging für die Envoy-Proxys aktivieren möchten, verwenden Sie die Parameter --service-proxy-labels oder --service-proxy access-log.

Beispiel:

gcloud compute instance-templates create td-vm-template-auto \
   --service-proxy enabled,access-log=/var/log/envoy/access.log,network=default \
   --service-proxy-labels myapp=review,version=canary

Der Envoy-Proxy kann die Systemdiagnoseports für Dienste auf den VMs abfangen. In diesem Fall erstellen die Systemdiagnoseprüfungen einen Bericht über Ihre Anwendung und Envoy-Proxys. Traffic wird nicht an die VM weitergeleitet, wenn der Envoy-Proxy nicht ordnungsgemäß ausgeführt wird. Beispiel:

gcloud compute instance-templates create td-vm-template-auto \
  --service-proxy=enabled,serving-ports="80;8080"

Aktualisierungsprozess für verwaltete Instanzgruppen verwenden

Wenn Sie die automatisierten Prozesse für die Konfiguration der Envoy-Proxys verwendet haben, können Sie den Aktualisierungsprozess für verwaltete Instanzgruppen nutzen, um die verwaltete Instanzgruppe zu aktualisieren. Verwenden Sie diesen Prozess in folgenden Fällen:

Fügen Sie die Dienst-Proxy-Komponenten einer vorhandenen verwalteten Instanzgruppe hinzu und registrieren Sie sie in einem Cloud Service Mesh-Netzwerk.
Aktualisieren der Dienstproxykomponenten auf den VMs

Führen Sie die folgenden Schritte aus, bevor Sie das Rolling Update durchführen:

Setzen Sie den Verbindungsausgleich für den Back-End-Dienst auf einen Wert von mindestens 30 Sekunden.
Verwenden Sie beim Aufrufen des Updaters den Parameter --min-ready, der auf einen Wert von mindestens 3 Minuten gesetzt ist. Der Parameter --min-ready legt fest, dass die verwaltete Instanzgruppe nach dem Aktualisieren einer VM wartet, bevor die nächste VM aktualisiert wird. Ohne diesen Schritt hat die neu erstellte VM keine Zeit, um Envoy und den Dienstproxy-Agent vollständig zu starten. Die Aktualisierung wird zu schnell fortgesetzt.

Führen Sie die folgenden Schritte aus, um das Rolling Update für die verwaltete Instanzgruppe durchzuführen.

Erstellen Sie wie oben beschrieben eine neue Instanzvorlage mit den Dienstproxyinformationen. Die ursprüngliche Version der Instanzvorlage kann für die Aktualisierung verwendet werden, wenn sie die Dienstproxyinformationen enthält und Ihr Ziel darin besteht, auf die neueste stabile Version der Proxysoftware zu aktualisieren.
Führen Sie ein Rolling Update der verwalteten Instanzgruppe durch. Legen Sie REPLACE als Mindestaktion fest, die der Updater ausführen muss. Die Instanzgruppe installiert die neueste Version der Proxysoftware und konfiguriert sie wie in der Instanzvorlage angegeben.

Mit dem Aktualisierungsprozess können Sie auch die Dienstproxykomponenten aus einer verwalteten Instanzgruppe entfernen:

Erstellen Sie eine neue Instanzvorlage, ohne das Flag --service-proxy anzugeben.
Führen Sie ein Rolling Update mithilfe des Aktualisierungsvorgangs für verwaltete Instanzgruppen durch.

Dadurch wird der Envoy-Proxy von Ihren VMs entfernt. Wenn diese verwaltete Instanzgruppe die einzige MIG war, die an den Back-End-Dienst angehängt ist, sollten Sie die Cloud Service Mesh-Konfiguration entfernen, die Sie beim Einrichten von Cloud Service Mesh erstellt haben.