Google Kubernetes Engine-Pods mit manueller Envoy-Injektion einrichten

In dieser Anleitung erfahren Sie, wie Sie Google Kubernetes Engine- oder Kubernetes-Pod-Hosts und die Load-Balancing-Komponenten konfigurieren, die für Cloud Service Mesh erforderlich sind.

Bevor Sie der Anleitung in diesem Leitfaden folgen, lesen Sie den Abschnitt Cloud Service Mesh-Einrichtung vorbereiten und prüfen Sie, ob die Voraussetzungen erfüllt sind.

Sie können Cloud Service Mesh mit dem Compute Engine Load Balancing SDK oder den REST APIs konfigurieren. Weitere Informationen finden Sie in den Load-Balancing API- und gcloud-Referenzen.

GKE-/Kubernetes-Cluster für Cloud Service Mesh konfigurieren

In diesem Abschnitt werden die erforderlichen Schritte zum Aktivieren von GKE-/Kubernetes-Clustern für die Arbeit mit Cloud Service Mesh beschrieben.

GKE-Cluster erstellen

GKE-Cluster müssen die folgenden Voraussetzungen erfüllen:

Das folgende Beispiel zeigt, wie Sie einen GKE-Cluster mit dem Namen traffic-director-cluster in der Zone us-central1-a erstellen.

Console

Zum Erstellen eines Clusters mit der Google Cloud Console führen Sie die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud Console das Menü „Kubernetes Engine” auf.

    Zum Kubernetes Engine-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Füllen Sie die folgenden Felder aus:

    • Name: Geben Sie traffic-director-cluster ein.
    • Standorttyp: Zonal.
    • Zone: us-central1-a.

  4. Klicken Sie im Navigationsbereich unter Knotenpools auf default-pool.

  5. Das Feld Größe gibt die Anzahl der Knoten an, die im Cluster erstellt werden sollen. Sie müssen verfügbare Ressourcenkontingente für die Knoten und ihre Ressourcen (z. B. Firewallrouten) haben.

  6. Klicken Sie im Navigationsbereich unter Standardpool auf Knoten.

  7. Das Feld Maschinentyp gibt den Compute Engine-Maschinentyp an, der für die Instanzen verwendet werden soll. Jeder Maschinentyp wird unterschiedlich abgerechnet. Informationen zu Preisen für Maschinentypen finden Sie auf der Preisübersicht für Compute Engine.

  8. Klicken Sie im Navigationsbereich unter Standardpool auf Sicherheit.

  9. Klicken Sie unter Zugriffsbereiche auf Uneingeschränkten Zugriff auf alle Cloud APIs zulassen.

  10. Passen Sie den Cluster nach Bedarf an.

  11. Klicken Sie auf Erstellen.

Nachdem Sie einen Cluster in der Google Cloud Console erstellt haben, müssen Sie kubectl für die Interaktion mit dem Cluster konfigurieren. Weitere Informationen finden Sie unter Eintrag in kubeconfig generieren.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Erforderliche GKE-Clusterberechtigungen abrufen

Wechseln Sie in GKE zum gerade erstellten Cluster (2). Führen Sie dafür den folgenden Befehl aus. Dadurch wird kubectl auf den richtigen Cluster verwiesen.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

GKE/Kubernetes-Dienste konfigurieren

In diesem Abschnitt wird gezeigt, wie Sie die Kubernetes-Bereitstellungsspezifikationen für die Arbeit mit Cloud Service Mesh vorbereiten. Dazu werden Dienste mit NEGs konfiguriert und Sidecar-Proxys in Pods eingefügt, die Zugriff auf die von Cloud Service Mesh verwalteten Dienste benötigen.

Firewallregel konfigurieren

Wenn Sie prüfen möchten, ob die Back-End-Pods ausgeführt werden, müssen Sie eine Firewallregel konfigurieren, die die IP-Adressbereiche der Systemdiagnose zulässt.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Firewallrichtlinien auf.
    Zur Seite „Firewallrichtlinien“
  2. Klicken Sie auf Firewallregeln erstellen.
  3. Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:
    • Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel fw-allow-health-checks.
    • Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
    • Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
    • Traffic-Richtung: Wählen Sie eingehend aus.
    • Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
    • Ziele: Wählen Sie Alle Instanzen im Netzwerk aus.
    • Quellfilter: Wählen Sie den richtigen IP-Bereichstyp aus.
    • Quell-IP-Bereiche: 35.191.0.0/16,130.211.0.0/22
    • Zielfilter: Wählen Sie den IP-Typ aus.
    • Protokolle und Ports: Klicken Sie auf Angegebene Ports und Protokolle und dann auf tcp. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
    • Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie mit dem folgenden gcloud-Befehl eine Firewallregel mit dem Namen fw-allow-health-checks, die eingehende Verbindungen zu Instanzen in Ihrem Netzwerk mit dem Tag allow-health-checks zulässt. Ersetzen Sie NETWORK_NAME durch den Namen Ihres Netzwerks.

    gcloud compute firewall-rules create fw-allow-health-checks \
    --network NETWORK_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges 35.191.0.0/16,130.211.0.0/22 \
    --rules tcp

Weitere Informationen finden Sie unter Erforderliche Firewallregeln.

GKE/Kubernetes-Dienste mit NEGs konfigurieren

GKE-Dienste müssen über Netzwerk-Endpunktgruppen (NEGs) verfügbar gemacht werden, damit Sie sie als Back-Ends eines Back-End-Dienstes von Cloud Service Mesh konfigurieren können. Fügen Sie der Kubernetes-Dienstspezifikation die NEG-Annotation hinzu und wählen Sie einen Namen aus, indem Sie NEG-NAME im Beispiel unten ersetzen, damit Sie sie später leicht wiederfinden. Sie benötigen den Namen, wenn Sie die NEG an den Back-End-Dienst von Cloud Service Mesh anhängen. Weitere Informationen zum Annotieren von NEGs finden Sie unter NEGs benennen.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Für jeden Dienst wird eine eigenständige NEG erstellt, deren Endpunkte die IP-Adressen und Ports des Pods sind. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.

Zu Demonstrationszwecken können Sie einen Beispieldienst bereitstellen, der seinen Hostnamen über HTTP an Port 80 sendet:

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Prüfen Sie, ob der neue Diensthostname erstellt wurde und der Anwendungs-Pod ausgeführt wird:

kubectl get svc

Dadurch wird Folgendes zurückgegeben:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]


kubectl get pods

Dadurch wird Folgendes zurückgegeben:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Name der NEG speichern

Suchen Sie die NEG, die im obigen Beispiel erstellt wurde, und notieren Sie den Namen der NEG.

Console

Sie können sich eine Liste der Netzwerk-Endpunktgruppen anzeigen lassen. Rufen Sie dazu die Seite "Netzwerk-Endpunktgruppen" in der Google Cloud Console auf.
Zur Seite Netzwerk-Endpunktgruppen

gcloud

gcloud compute network-endpoint-groups list

Es wird Folgendes zurückgegeben:

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

Speichern Sie den NEG-Namen in der Variablen NEG_NAME. Beispiel:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Google Cloud-Load-Balancing-Komponenten für Cloud Service Mesh konfigurieren

Mit den Anleitungen in diesem Abschnitt wird sichergestellt, dass GKE-Dienste über die virtuelle IP-Adresse des Dienstes zugänglich sind, deren Load-Balancing durch Cloud Service Mesh erfolgt. Dabei wird eine Load-Balancing-Konfiguration verwendet, die anderen Google Cloud Load Balancing-Produkten ähnelt.

Sie müssen die folgenden Komponenten konfigurieren:

Im folgenden Cloud Service Mesh-Konfigurationsbeispiel wird von diesen Annahmen ausgegangen:

  1. Die NEGs und alle anderen Ressourcen werden im default-Netzwerk mit automatischem Modus in der Zone us-central1-a erstellt.
  2. Der NEG-Name für den Cluster wird in der Variable ${NEG_NAME} gespeichert.

Systemdiagnose erstellen

Erstellen Sie die Systemdiagnose:

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf Systemdiagnose erstellen.
  3. Geben Sie als Name td-gke-health-check ein.
  4. Wählen Sie als Protokoll HTTP aus.
  5. Klicken Sie auf Erstellen.

gcloud 

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

Back-End-Dienst erstellen

Erstellen Sie einen globalen Backend-Dienst mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED. In der Google Cloud Console wird das Load-Balancing-Schema implizit festgelegt. Binden Sie die Systemdiagnose in den Backend-Dienst ein.

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Cloud Service Mesh“ auf.

    Zur Seite „Cloud Service Mesh“

  2. Klicken Sie auf dem Tab Dienste auf Dienst erstellen.

  3. Klicken Sie auf Weiter.

  4. Geben Sie als Dienstname td-gke-service ein.

  5. Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.

  6. Wählen Sie die erstellte Netzwerk-Endpunktgruppe aus.

  7. Legen Sie die Maximale Anzahl der Anfragen pro Sekunde auf 5 fest.

  8. Klicken Sie auf Fertig.

  9. Wählen Sie unter Systemdiagnose td-gke-health-check aus. Dies ist die Systemdiagnose, die Sie erstellt haben.

  10. Klicken Sie auf Weiter.

gcloud

  1. Erstellen Sie den Back-End-Dienst und verknüpfen Sie die Systemdiagnose mit dem Back-End-Dienst.

    gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

  2. Fügen Sie dem Back-End-Dienst die Back-End-NEGs hinzu.

    gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone us-central1-a \
 --balancing-mode RATE \
 --max-rate-per-endpoint 5

Routingregelzuordnung erstellen

Folgen Sie dieser Anleitung, um die Routingregel, die Weiterleitungsregel und die interne IP-Adresse für Ihre Cloud Service Mesh-Konfiguration zu erstellen.

Der an die interne IP-Adresse gesendete Traffic wird vom Envoy-Proxy abgefangen und gemäß den Host- und Pfadregeln an den entsprechenden Dienst gesendet.

Die Weiterleitungsregel wird als globale Weiterleitungsregel erstellt, wobei load-balancing-scheme auf INTERNAL_SELF_MANAGED gesetzt ist.

Sie können die Adresse Ihrer Weiterleitungsregel auf 0.0.0.0 festlegen. Dabei wird der Traffic basierend auf dem in der URL-Zuordnung konfigurierten HTTP-Hostnamen und den Pfadinformationen weitergeleitet, unabhängig von der tatsächlichen IP-Adresse, in die der Hostname aufgelöst wird. In diesem Fall müssen die URLs (Hostname und URL-Pfad) Ihrer Dienste gemäß den Hostregeln in der Service Mesh-Konfiguration eindeutig sein. Sie können z. B. nicht zwei verschiedene Dienste mit unterschiedlichen Back-Ends haben, die beide dieselbe Kombination aus Hostname und Pfad verwenden.

Alternativ können Sie das Routing basierend auf der tatsächlichen Ziel-VIP des Dienstes aktivieren. Wenn Sie die VIP Ihres Dienstes als address-Parameter der Weiterleitungsregel konfigurieren, werden anhand der in der URL-Zuordnung angegebenen HTTP-Parameter nur Anfragen an diese IP-Adresse weitergeleitet.

Console

In der Console wird der Zielproxy mit der Weiterleitungsregel kombiniert. Wenn Sie die Weiterleitungsregel erstellen, erstellt Google Cloud automatisch einen Ziel-HTTP-Proxy und verknüpft ihn mit der URL-Zuordnung.

Die Routingregel besteht aus der Weiterleitungsregel und den Host- und Pfadregeln (auch als URL-Zuordnung bezeichnet).

  1. Rufen Sie in der Google Cloud Console die Seite „Cloud Service Mesh“ auf.

    Zur Seite „Cloud Service Mesh“

  2. Klicken Sie auf Routingregelzuordnungen.

  3. Klicken Sie auf Routingregel erstellen.

  4. Geben Sie als Name der URL-Zuordnung td-gke-url-map ein.

  5. Klicken Sie auf Weiterleitungsregel hinzufügen.

  6. Geben Sie als Name für die Weiterleitungsregel td-gke-forwarding-rule ein.

  7. Wählen Sie das Netzwerk aus.

  8. Wählen Sie Ihre Interne IP-Adresse aus.

  9. Klicken Sie auf Speichern.

  10. Fügen Sie optional benutzerdefinierte Host- und Pfadregeln hinzu oder behalten Sie die Pfadregeln als Standard bei.

  11. Legen Sie den Host auf service-test fest.

  12. Klicken Sie auf Speichern.

gcloud

  1. Erstellen Sie eine URL-Zuordnung, die den Back-End-Dienst verwendet.

    gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

  2. Erstellen Sie ein Tool zum Abgleich von Pfaden für URL-Zuordnungen und eine Hostregel, um den Traffic für Ihren Dienst auf Grundlage des Hostnamens und Pfads weiterzuleiten. In diesem Beispiel werden service-test als Dienstname und ein Standardtool zum Abgleich von Pfaden verwendet, das mit allen Pfadanfragen für diesen Host (/*) übereinstimmt. service-test ist auch der konfigurierte Name des Kubernetes-Dienstes, der in der obigen Beispielkonfiguration verwendet wird.

    gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

    gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher

  3. Erstellen Sie den Ziel-HTTP-Proxy.

    gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

  4. Erstellen Sie die Weiterleitungsregel.

    gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

An dieser Stelle ist Cloud Service Mesh so konfiguriert, dass das Load-Balancing des Traffics für die in der URL-Zuordnung angegebenen Dienste über Back-Ends in der Netzwerk-Endpunktgruppe erfolgt.

Je nachdem, wie Ihre Mikrodienste in Ihrem Netzwerk verteilt sind, müssen Sie möglicherweise weitere Weiterleitungsregeln oder weitere Host- und Pfadregeln zur URL-Zuordnung hinzufügen.

Konfiguration durch Bereitstellung eines Beispielclients für Tests prüfen

In diesem Abschnitt wird gezeigt, wie Sie Cloud Service Mesh-Back-Ends über eine Clientanwendung erreichen.

Zur Demonstration der Funktionalität können Sie einen Beispiel-Pod bereitstellen, auf dem Livelybox ausgeführt wird. Der Pod hat Zugriff auf service-test, der im vorherigen Abschnitt erstellt wurde und Traffic empfängt, der durch Cloud Service Mesh verteilt wird.

Sidecar-Proxy in GKE/Kubernetes-Pods einfügen

Für den Zugriff auf einen von Cloud Service Mesh verwalteten Dienst muss auf einem Pod ein xDS API-kompatibler Sidecar-Proxy installiert sein.

In diesem Beispiel stellen Sie einen Busybox-Client mit einem Istio-Proxy-Sidecar und init-Containern bereit, die mithilfe der Referenzspezifikation zur Bereitstellung hinzugefügt wurden:

Wenn Sie die älteren APIs verwenden, ersetzen Sie die Variablen PROJECT_NUMBER und NETWORK_NAME durch Ihre Projektnummer und Ihren Netzwerknamen:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

Wenn Sie die neuen Service Routing APIs verwenden, die sich derzeit in der Vorschau befinden, ersetzen Sie die Variablen PROJECT_NUMBER und MESH_NAME durch die Projektnummer und den Mesh-Namen:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

Im Busybox-Pod sind zwei Container aktiv. Der erste Container ist der Client, der auf dem Busybox-Image beruht, und der zweite Container ist der als Sidecar eingefügte Envoy-Proxy. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:

kubectl describe pods -l run=client

Auf Backend-Dienst zugreifen

Nach der Konfiguration können Anwendungen auf Pods mit eingefügtem Sidecar-Proxy auf Dienste zugreifen, die von Cloud Service Mesh-Diensten verwaltet werden. Zum Prüfen der Konfiguration können Sie in einem der Container auf eine Shell zugreifen.

Wenn Sie die in dieser Anleitung enthaltene Demokonfiguration verwendet haben, können Sie mit dem folgenden Befehl prüfen, ob der Hostname des Bereitstellungs-Pods zurückgegeben wird.

# Get name of the Pod  with busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Informationen zum Abfangen von Traffic durch den Sidecar-Proxy

Wenn der Livelybox-Client in diesem Beispiel Anfragen an den Back-End-Dienst sendet, wird jede Anfrage vom Sidecar-Proxy weitergeleitet.

Diese Demoanwendung verwendet den Envoy-Proxy. Aus diesem Grund sieht der Client "server: envoy" im Header der Serverantworten.

Verwenden Sie zur Bestätigung die folgenden Befehle:

# Get the name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

In diesem Beispiel haben Sie eine Weiterleitungsregel mit der VIP-Adresse 0.0.0.0 erstellt. Dies bedeutet, dass Cloud Service Mesh Anfragen nur basierend auf dem Header Host an das Back-End weiterleitet. In diesem Fall kann die Ziel-IP-Adresse eine beliebige Adresse sein, solange der Anfrage-Hostheader mit dem in der URL-Zuordnung service-test definierten Host übereinstimmt.

Führen Sie die folgenden Testbefehle aus, um dies zu bestätigen:

# Get name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Nächste Schritte