Leitfaden zu den Optionen für die automatisierte Envoy-Bereitstellung

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

Zusätzliche Optionen zur Erstellung von Instanzvorlagen

Wenn Sie eine Instanzvorlage für die automatisierte Envoy-Proxy-Bereitstellung erstellen, können Sie die folgenden Parameter verwenden, um einige Aspekte der Bereitstellung und das Verhalten der Proxys zu 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 Sie den Dienstproxy automatisch bereitstellen und konfigurieren möchten. 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, über die 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 von 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 Traffic ab und leitet ihn zur Verarbeitung vom Dienstproxy an diesen Port weiter.
Optional
Wenn Sie dieses Flag weglassen, wird standardmäßig 15001 verwendet.
--service-proxy:network Der Name eines gültigen VPC-Netzwerks.
Das Google Cloud VPC-Netzwerk, das von der Steuerungsebene des Dienstproxys zum Generieren der dynamischen Konfiguration für den Dienstproxy verwendet wird.
Erforderlich, wenn sich die VM in mehreren Netzwerken befindet. Andernfalls ist dies optional.
Wenn Sie dieses Flag weglassen, wird der Wert verwendet, der beim Erstellen der VM-Instanzvorlage mit dem Parameter --network angegeben wird.
--service-proxy:tracing ON oder OFF
Der Dienstproxy kann verteilte Tracing-Informationen generieren. Wenn dieser Wert auf ON gesetzt ist, generiert die Steuerungsebene des Dienstproxys eine Konfiguration, die das Anforderungs-ID-basierte Tracing ermöglicht.
Weitere Informationen finden Sie in der generate_request_id-Dokumentation für den Envoy-Proxy.
Optional.
Wenn Sie dieses Flag weglassen, wird 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 Default-Wert. Wenn Sie den Dateipfad nicht angeben, werden die Logs nicht erstellt.
--service-proxy-labels Schlüssel/Wert-Paare im Format key=value.
Labels, die Sie auf Ihren Dienstproxy anwenden können. Diese werden in den Bootstrap-Metadaten Ihres Envoy-Proxys angezeigt. Die Labels können beliebige key=value-Paare sein, die Sie als Proxy-Metadaten festlegen möchten, z. B. für die Konfigurationsfilterung. Sie können diese Flags für Anwendungs- und Versionslabels verwenden, z. B. app=review oder version=canary. Sie können diese auch zusammen verwenden.
Optional

Mit dem folgenden gcloud-Befehl wird beispielsweise eine Instanzvorlage namens proxy-it erstellt. Bei Instanzen, die über diese Vorlage erstellt wurden, sind der Envoy-Proxy und der Dienst-Proxy-Agent installiert.

gcloud beta 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 werden installiert, der Bereitstellungsport und der Proxy-Port sind festgelegt, das Tracing ist aktiviert und ein Label ist definiert.

gcloud beta 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, die den TCP-Port 8080 überwacht, weiterleitet. Außerdem gilt:

  • Alle ausgehenden Verbindungen zu den VIPs von in Traffic Director konfigurierten Diensten werden von iptables abgefangen, das auch netfilter konfiguriert. Netfilter stellt sicher, dass der entsprechende Traffic, der den Netzwerk-Stack durchläuft, abgefangen und an den Envoy-Proxy weitergeleitet wird. Der Traffic wird dann entsprechend der Konfiguration von Traffic Director verteilt.
  • Alle anderen eingehenden Verbindungen werden von iptables nicht abgefangen und direkt an Dienste auf der VM weitergeleitet.
  • Alle Verbindungen zu externen Endpunkten werden direkt an externe IP-Adressen weitergeleitet, ohne abgefangen zu werden.
  • Der gesamte UDP-Traffic wird direkt an das Ziel weitergeleitet, ohne von iptables abgefangen zu werden.

Dies ist im folgenden Diagramm dargestellt.

Traffic-Verteilung mit Traffic Director (zum Vergrößern klicken)
Traffic-Verteilung mit Traffic Director (zum Vergrößern klicken)

Der Trafficfluss im Diagramm sieht so aus:

  1. Eingehender Traffic mit Zielport 80, der nicht abgefangen und direkt an den Dienst weitergeleitet wird, der den Port überwacht.
  2. Eingehender Traffic mit Zielport 8080, abgefangen und an den Envoy-Listener-Port weitergeleitet.
  3. Envoy leitet Traffic von (2) an Dienst 2 weiter, der den Localhost-Port 8080 überwacht.
  4. Ausgehender Traffic, der an die VIP und den Port der Traffic Director-Weiterleitungsregel gerichtet ist, wird abgefangen und an den Envoy-Listener-Port weitergeleitet.
  5. Envoy leitet Traffic von (4) an den Endpunkt des Back-Ends des Traffic Director-Back-End-Dienstes weiter.
  6. Ausgehender Traffic, der nicht an Traffic Director VIP und Port gerichtet, nicht abgefangen und direkt an einen externen Dienst weitergeleitet wird.

Labels verwenden

Wenn Sie Labels für die Traffic Director-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 melden die Systemdiagnoseprüfungen Ihrer Anwendung und auf den Envoy-Proxys. Der 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 den automatisierten Prozess zum Konfigurieren der Envoy-Proxys verwendet haben, können Sie den Aktualisierungsprozess für verwaltete Instanzgruppen zum Aktualisieren Ihrer verwalteten Instanzgruppe verwenden. Mit diesem Verfahren können Sie:

  • Fügen Sie die Dienstproxykomponenten einer vorhandenen verwalteten Instanzgruppe hinzu und registrieren Sie sie in einem Traffic Director-Netzwerk.
  • Aktualisieren Sie die Dienstproxykomponenten auf den VMs.

Führen Sie vor dem Rolling Update folgende Schritte aus.

  1. Stellen Sie den Verbindungsausgleich für den Back-End-Dienst auf mindestens 30 Sekunden ein.
  2. Verwenden Sie den Parameter --min-ready, der auf 3 Minuten oder länger eingestellt ist, wenn Sie den Updater aufrufen. Der Parameter --min-ready sorgt dafür, dass die verwaltete Instanzgruppe nach der Aktualisierung einer VM wartet, bevor sie mit der Aktualisierung der nächsten VM fortfährt. Ohne diese Zeit hat die neu erstellte VM keine Zeit, den 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.

  1. Erstellen Sie wie oben beschrieben eine neue Instanzvorlage mit den Dienstproxyinformationen. Die Originalversion der Instanzvorlage kann für die Aktualisierung verwendet werden, wenn sie die Dienstproxyinformationen enthält und Sie ein Update auf die neueste stabile Version der Proxysoftware durchführen möchten.
  2. Führen Sie ein Rolling Update der verwalteten Instanzgruppe durch. Achten Sie darauf, REPLACE als Mindestaktion festzulegen, die der Updater ausführen muss. Die Instanzgruppe installiert die neueste Version der Proxysoftware und konfiguriert sie wie in der Instanzvorlage angegeben.

Außerdem können Sie die Dienst-Proxy-Komponenten mithilfe eines Aktualisierungsvorgangs aus einer verwalteten Instanzgruppe entfernen:

  1. Erstellen Sie eine neue Instanzvorlage, ohne das Flag --service-proxy anzugeben.

  2. Führen Sie ein Rolling Update mit dem Aktualisierungsprozess der verwalteten Instanzgruppe durch.

Dadurch wird der Envoy-Proxy von Ihren VMs entfernt. Wenn diese verwaltete Instanzgruppe die einzige MIG war, die mit dem Back-End-Dienst verbunden ist, sollten Sie die Traffic Director-Konfiguration entfernen, die Sie bei der Einrichtung von Traffic Director erstellt haben.