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-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 Dienste, die in Traffic Director konfiguriert sind, 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. Für den Traffic erfolgt das Load-Balancing dann entsprechend der Traffic Director-Konfiguration.
  • 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:

Traffiverteilung mit Traffic Director (zum Vergrößern klicken)
Trafficverteilung mit Traffic Director (zum Vergrößern klicken)

Die Trafficflüsse im Diagramm sehen so aus:

  1. Eingehender Traffic mit Zielport 80, nicht abgefangen und direkt an den Dienst weitergeleitet, 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 für VIP und Port der Traffic Director-Weiterleitungsregel bestimmt ist, abgefangen und an den Envoy-Listener-Port weitergeleitet.
  5. Envoy leitet Traffic von (4) an den Endpunkt des Back-Ends des Back-End-Zieldienstes für Traffic Director weiter.
  6. Ausgehender Traffic, der für Nicht-Traffic Director-VIP und -Port gilt, nicht abgefangen und direkt an externen Dienst weitergeleitet.

Labels verwenden

Wenn Sie Labels für die Metadatenfilterung in Traffic Director 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:

  • Hinzufügen der Dienstproxykomponenten zu einer vorhandenen verwalteten Instanzgruppe und Registrieren für ein Traffic Director-Netzwerk
  • Aktualisieren der Dienstproxykomponenten auf den VMs

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

  1. Setzen Sie den Verbindungsausgleich für den Back-End-Dienst auf einen Wert von mindestens 30 Sekunden.
  2. 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.

  1. 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.
  2. 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:

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

  2. 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 Traffic Director-Konfiguration entfernen, die Sie beim Einrichten von Traffic Director erstellt haben.