Google Kubernetes Engine-Pods mit automatischer Envoy-Injektion einrichten

Übersicht

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Google Cloud APIs und keine Istio APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

In einem Service Mesh muss Ihr Anwendungscode Ihre Netzwerkkonfiguration nicht kennen. Stattdessen kommunizieren Ihre Anwendungen über eine Datenebene. Diese wird von einer Steuerungsebene konfiguriert, die das Dienstnetzwerk verwaltet. In dieser Anleitung ist Cloud Service Mesh Ihre Steuerungsebene und die Envoy-Sidecar-Proxys sind Ihre Datenebene.

Der von Google verwaltete Envoy-Sidecar-Injektor fügt Ihren Google Kubernetes Engine-Pods Envoy-Sidecar-Proxys hinzu. Wenn der Envoy-Sidecar-Injektor einen Proxy hinzufügt, wird dieser Proxy auch für die Verarbeitung des Anwendungstraffics und die Verbindung mit Cloud Service Mesh eingerichtet, damit Sie Ihre gewünschten Konfigurationen vornehmen können.

Der Leitfaden führt Sie durch eine einfache Einrichtung von Cloud Service Mesh mit Google Kubernetes Engine. Diese Schritte sind die Grundlage, die Sie auf komplexere Anwendungsfälle erweitern können, z. B. ein Service Mesh, das sich über mehrere Google Kubernetes Engine-Cluster und potenziell auch Compute Engine-VMs erstreckt. Sie können diese Anleitung auch verwenden, wenn Sie Cloud Service Mesh mit einer freigegebene VPC konfigurieren.

Die Einrichtung umfasst Folgendes:

1. GKE-Cluster für Arbeitslasten erstellen
2. Envoy-Sidecar-Injektor installieren und Injektion aktivieren
3. Beispielclient bereitstellen und Injektion prüfen
4. Kubernetes-Dienst zum Testen bereitstellen
5. Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren, um Traffic an den Testdienst weiterzuleiten
6. Konfiguration durch Senden einer Anfrage vom Beispielclient an den Testdienst prüfen

Übersicht über die Komponenten, die im Rahmen dieses Einrichtungsleitfadens bereitgestellt werden (zum Vergrößern klicken)

Vorbereitung

Bevor Sie den Anleitungen in diesem Leitfaden folgen, führen Sie die unter Einrichtung von Service Routing APIs mit Envoy und proxylosen Workloads vorbereiten beschriebenen vorbereitenden Aufgaben aus.

Informationen zur unterstützten Envoy-Version finden Sie in den Versionshinweisen zu Cloud Service Mesh.

Hinweis: Der Sidecar-Injektor und der eingefügte Proxy basieren auf dem Sidecar-Injektor von Istio. Installieren Sie den Envoy-Sidecar-Injektor nicht, wenn Sie Istio bereits für Ihren GKE-Cluster bereitgestellt haben, da dies zu Konflikten beim Injektionsverhalten führen kann.

Zusätzliche Voraussetzungen für freigegebene VPC

Wenn Sie Cloud Service Mesh in einer Umgebung mit freigegebene VPC einrichten, müssen Sie Folgendes beachten:

• Sie haben die richtigen Berechtigungen und Rollen für die freigegebene VPC.
• Sie haben die richtigen Projekte und die Abrechnung eingerichtet.
• Sie haben die Abrechnung in den Projekten aktiviert.
• Sie haben die Cloud Service Mesh- und GKE APIs in jedem Projekt aktiviert, einschließlich des Hostprojekts.
• Sie haben für jedes Projekt die richtigen Dienstkonten eingerichtet.
• Sie haben ein VPC-Netzwerk und Subnetze erstellt.
• Sie haben die Funktion „Freigegebene VPC“ aktiviert.

Weitere Informationen finden Sie unter Freigegebene VPC.

IAM-Rollen konfigurieren

In diesem Beispiel für die Konfiguration von IAM-Rollen wird davon ausgegangen, dass das Hostprojekt für die freigegebene VPC zwei Subnetze und dass es in der freigegebenen VPC zwei Dienstprojekte gibt.

1. Erstellen Sie in Cloud Shell einen Arbeitsordner (WORKDIR), in dem Sie die mit diesem Abschnitt verknüpften Dateien erstellen:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. Konfigurieren Sie IAM-Berechtigungen im Hostprojekt, damit Dienstprojekte die Ressourcen in der freigegebenen VPC verwenden können.

   In diesem Schritt konfigurieren Sie die IAM-Berechtigungen, sodass Dienstprojekt 1 auf subnet-1 und Dienstprojekt 2 auf subnet-2 zugreifen kann. Sie weisen die IAM-Rolle „Compute-Netzwerknutzer“ (roles/compute.networkUser) in jedem Dienstprojekt für jedes Subnetz sowohl dem Compute Engine-Standarddienstkonto als auch dem Google Cloud API-Dienstkonto zu.

   1. Konfigurieren Sie für Dienstprojekt 1 IAM-Berechtigungen für subnet-1:

      export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')
      
      cat > subnet-1-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_1_API_SA}
        - serviceAccount:${SVC_PROJECT_1_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_1_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-1 \
      subnet-1-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_1}
      

   2. Konfigurieren Sie für Dienstprojekt 2 IAM-Berechtigungen für subnet-2:

      export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')
      
      cat > subnet-2-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_2_API_SA}
        - serviceAccount:${SVC_PROJECT_2_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_2_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-2 \
      subnet-2-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_2}
      

3. Für jedes Dienstprojekt müssen Sie dem GKE-Dienstkonto im Hostprojekt die IAM-Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ (roles/container.hostServiceAgentUser) zuweisen:

   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   
   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   

   Damit kann das GKE-Dienstkonto des Dienstprojekts das GKE-Dienstkonto des Hostprojekts verwenden, um gemeinsam genutzte Netzwerkressourcen zu konfigurieren.

4. Weisen Sie dem Compute Engine-Standarddienstkonto für jedes Dienstprojekt die IAM-Rolle „Compute-Netzwerkbetrachter“ (roles/compute.networkViewer) im Hostprojekt zu.

   gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
       --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
       --role roles/compute.networkViewer
   
   gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
       --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
       --role roles/compute.networkViewer
   

   Wenn der Envoy-Sidecar-Proxy mit dem xDS-Dienst (Traffic Director API) verbunden ist, verwendet der Proxy das Dienstkonto des Compute Engine-VM-Hosts (virtuelle Maschine) oder der GKE-Knoteninstanz. Das Dienstkonto muss die IAM-Berechtigung compute.globalForwardingRules.get auf Projektebene haben. Die Rolle "Compute-Netzwerkbetrachter" ist für diesen Schritt ausreichend.

Projektinformationen konfigurieren

Wenn Sie noch kein Google Cloud-Projekt erstellt oder die Google Cloud CLI nicht installiert haben, folgen Sie dieser Anleitung. Wenn Sie kubectl noch nicht installiert haben, folgen Sie dieser Anleitung.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should match the channel of your GKE cluster.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

Wenn Sie die neuen Service Routing APIs verwenden, können Sie MESH_NAME, MESH_PROJECT_NUMBER und TARGET so festlegen:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

In den meisten Fällen beziehen sich CLUSTER_PROJECT_ID und MESH_PROJECT_NUMBER auf dasselbe Projekt. Wenn Sie jedoch ein anderes Projekt einrichten, z. B. bei Verwendung einer freigegebene VPC, bezieht sich CLUSTER_PROJECT_ID auf die Projekt-ID, die Ihren GKE-Cluster enthält, und MESH_PROJECT_NUMBER auf die Projektnummer, die die Ressourcen enthält. Achten Sie darauf, dass Sie die entsprechenden Berechtigungen konfiguriert haben, damit der eingeschleuste Envoy Konfigurationen aus dem

Mesh Config API aktivieren

Aktivieren Sie die folgende API, um mit dem von Google verwalteten Sidecar-Injector zu beginnen.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

GKE-Cluster für Arbeitslasten erstellen

GKE-Cluster müssen die folgenden Voraussetzungen für die Unterstützung von Cloud Service Mesh erfüllen:

• Die Unterstützung von Netzwerk-Endpunktgruppen muss aktiviert sein. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.
• Das Dienstkonto für Ihre GKE-Knoten/Pods muss die Berechtigung für den Zugriff auf die Traffic Director API haben. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Dienstkonto für den Zugriff auf die Traffic Director API aktivieren.

GKE-Cluster erstellen

Erstellen Sie einen GKE-Cluster in Ihrer bevorzugten Zone, z. B. us-central1-a.

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

kubectl auf den neu erstellten Cluster verweisen

Ändern Sie den aktuellen Kontext für kubectl in den neu erstellten Cluster. Führen Sie dazu den folgenden Befehl aus:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Konfigurationen für Mutating Webhook anwenden

In den folgenden Abschnitten wird beschrieben, wie Sie die MutatingWebhookConfiguration auf den Cluster anwenden. Wenn ein Pod erstellt wird, wird der clusterinterne Admission Controller aufgerufen. Der Admission Controller kommuniziert mit dem verwalteten Sidecar-Injektor, um dem Pod den Envoy-Container hinzuzufügen.

Wenden Sie die folgenden Webhook-Konfigurationen für Mutationen auf Ihren Cluster an.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

Sidecar-Injektion aktivieren

Mit dem folgenden Befehl wird die Injektion für den Namespace default aktiviert. Der Sidecar-Injektor fügt Sidecar-Container in Pods ein, die unter diesem Namespace erstellt werden:

kubectl label namespace default td-injection=enabled

Mit dem folgenden Befehl können Sie prüfen, ob der Namespace default richtig aktiviert ist:

kubectl get namespace -L td-injection

In diesem Fall sollte Folgendes zurückgegeben werden:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Wenn Sie die Dienstsicherheit für Cloud Service Mesh mit Envoy konfigurieren, kehren Sie zum Abschnitt Testdienst einrichten in dieser Einrichtungsanleitung zurück.

Beispielclient bereitstellen und Injektion prüfen

In diesem Abschnitt wird gezeigt, wie Sie einen Beispiel-Pod mit Busybox bereitstellen. Busybox bietet Ihnen eine einfache Schnittstelle zum Erreichen eines Testdienstes. In einer echten Bereitstellung würden Sie stattdessen Ihre eigene Clientanwendung bereitstellen.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

Der Busybox-Pod besteht aus zwei Containern. Der erste Container ist der Client, der auf dem Busybox-Image basiert, und der zweite Container ist der Envoy-Proxy, der vom Sidecar-Injektor eingefügt wird. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:

kubectl describe pods -l run=client

In diesem Fall sollte Folgendes zurückgegeben werden:

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Cloud Service Mesh-Proxy

Der verwaltete Sidecar-Injektor verwendet das Cloud Service Mesh-Proxy-Image als Proxy. Der Cloud Service Mesh-Proxy ist ein Sidecar-Container, der für das Starten eines Envoy-Proxys für meshfähige Instanzen verantwortlich ist. Das Proxy-Image verwendet das OSS-Envoy-Image zusammen mit einem Proxy-Agent, der für das Starten von Envoy, die Bereitstellung der Bootstrap-Konfiguration und die Prüfung des Gesundheitszustands von Envoy verantwortlich ist. Die Cloud Service Mesh-Proxy-Imageversionen entsprechen der OSS-Envoy-Version. Informationen zu den verfügbaren Proxy-Images finden Sie hier: https://gcr.io/gke-release/asm/csm-mesh-proxy

Der Cloud Service Mesh-Mesh-Proxy, der eingefügt wird, hängt vom Kanal ab, den der Nutzer für den GKE-Cluster ausgewählt hat. Die Envoy-Version wird regelmäßig anhand der aktuellen OSS-Envoy-Releases aktualisiert und mit der jeweiligen GKE-Version auf Kompatibilität getestet.

Cloud Service Mesh-Proxyversion

Die folgende Tabelle zeigt die Zuordnung des aktuellen GKE-Clusterkanals zur Cloud Service Mesh-Proxy-Version:

Kanal	Cloud Service Mesh-Proxyversion
Rapid	1.29.9-gke.3
Regulär	1.28.7-gke.3
Stabile Version	1.27.7-gke.3

Cloud Service Mesh-Proxy-Upgrade

Wir empfehlen dringend, ein Upgrade auf die neueste Version durchzuführen. Das Service Mesh ist in Ordnung, wenn sich die Steuerungsebene und die Proxys in verschiedenen Versionen befinden. Wir empfehlen jedoch, die Proxys so zu aktualisieren, dass sie mit der neuen Cloud Service Mesh-Version konfiguriert werden.

Der verwaltete Sidecar-Injektor kümmert sich um die Envoy-Version. Dabei wird immer die neueste von Google qualifizierte Envoy-Version injiziert. Wenn die Cloud Service Mesh Proxy-Version neuer als die Proxyversion ist, starten Sie die Proxys für Ihre Dienste neu.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Kubernetes-Dienst zum Testen bereitstellen

In den folgenden Abschnitten finden Sie eine Anleitung zum Einrichten eines Testdienstes, den Sie später in diesem Leitfaden verwenden, um eine End-to-End-Prüfung Ihrer Einrichtung zu ermöglichen.

GKE-Dienste mit NEGs konfigurieren

GKE-Dienste müssen über Netzwerk-Endpunktgruppen (NEGs) verfügbar gemacht werden, damit Sie sie als Back-Ends eines Cloud Service Mesh-Back-End-Dienstes 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 Ihren Cloud Service Mesh-Back-End-Dienst anhängen. Weitere Informationen zum Annotieren von NEGs finden Sie unter NEGs benennen.

Hinweis: Das in diesem Einrichtungshandbuch bereitgestellte Paket trafficdirector_service_sample.yaml verwendet den NEG-Namen service-test-neg.

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

Diese Annotation erstellt eine Standalone-NEG mit Endpunkten, die den IP-Adressen und Ports der Dienst-Pods entsprechen. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.

Der folgende Beispieldienst enthält die NEG-Annotation. Der Dienst stellt den Hostnamen über HTTP auf Port 80 bereit. Verwenden Sie den folgenden Befehl, um den Dienst abzurufen und im GKE-Cluster bereitzustellen.

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

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

kubectl get svc

Die Ausgabe sollte in etwa so aussehen:

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

Prüfen Sie, ob der mit diesem Dienst verknüpfte Anwendungs-Pod ausgeführt wird:

kubectl get pods

Dadurch wird Folgendes zurückgegeben:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Hinweis: Da der Sidecar-Injektor im Standard-Namespace aktiviert ist, werden Sidecar-Proxys auch in den Testdienst-Pod eingefügt, wenn dieser erstellt wird. Der Sidecar-Injektor konfiguriert nur das Abfangen von ausgehendem Traffic. Daher ist der Sidecar-Proxy des Testdienstes nicht an der Verarbeitung des eingehenden Traffics aus dem Beispielclient beteiligt.

Name der NEG speichern

Suchen Sie die im obigen Beispiel erstellte NEG und notieren Sie sich ihren Namen für die Cloud Service Mesh-Konfiguration im nächsten Abschnitt.

gcloud compute network-endpoint-groups list

Es wird Folgendes zurückgegeben:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Speichern Sie den Namen der NEG in der Variable NEG_NAME:

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

Hinweis: Wenn Sie Ihre NEG benannt haben, wie unter GKE-Dienste mit NEGs konfigurieren beschrieben, sollte der NEG-Name mit dem übereinstimmen, den Sie in der Kubernetes-Dienstspezifikation angegeben haben. Wenn Sie die NEG nicht benannt haben, wird automatisch ein Name generiert.

Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren

In diesem Abschnitt wird Cloud Service Mesh mithilfe von Compute Engine-Load Balancing-Ressourcen konfiguriert. Dadurch kann der Sidecar-Proxy des Beispielclients die Konfiguration von Cloud Service Mesh empfangen. Ausgehende Anfragen vom Beispielclient werden vom Sidecar-Proxy verarbeitet und an den Testdienst weitergeleitet.

Sie müssen die folgenden Komponenten konfigurieren:

• Systemdiagnose Weitere Informationen zu Systemdiagnosen finden Sie unter Konzepte der Systemdiagnose und Systemdiagnosen erstellen.
• Back-End-Dienst Weitere Informationen zu Back-End-Diensten finden Sie unter Back-End-Dienste.
• Eine Routingregelzuordnung: Dazu gehört das Erstellen einer Weiterleitungsregel, eines Ziel-HTTP-Proxys und einer URL-Zuordnung. Weitere Informationen finden Sie unter Weiterleitungsregeln für Cloud Service Mesh verwenden, Zielproxys für Cloud Service Mesh verwenden und URL-Zuordnungen verwenden.

Systemdiagnose und Firewallregel erstellen

Führen Sie die folgenden Schritte aus, um eine Systemdiagnose und die Firewallregel zu erstellen, die für die Systemdiagnoseprüfungen erforderlich sind. Weitere Informationen finden sich unter Firewallregeln für Systemdiagnosen.

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.

6. Rufen Sie in der Google Cloud Console die Seite Firewallrichtlinien auf.
   Zur Seite „Firewall-Richtlinien“

7. Klicken Sie auf Firewallregeln erstellen.

8. 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 setzen Sie ein Häkchen bei tcp. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
   • Klicken Sie auf Erstellen.

gcloud

1. Erstellen Sie die Systemdiagnose.

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

2. Erstellen Sie die Firewallregel, um IP-Adressbereiche für die Systemdiagnose zuzulassen.

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

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 Network aus, das Sie in der ConfigMap von Cloud Service Mesh konfiguriert haben.

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

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

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

9. Legen Sie den Balancing-Modus auf Rate fest.

10. Klicken Sie auf Fertig.

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

12. 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 zuvor erstellte NEG als Back-End hinzu. Wenn Sie Cloud Service Mesh mit einem Ziel-TCP-Proxy konfigurieren, müssen Sie den Balancing-Modus UTILIZATION verwenden. Wenn Sie einen HTTP- oder HTTPS-Zielproxy verwenden, können Sie den Modus RATE verwenden.

   gcloud compute backend-services add-backend td-gke-service \
    --global \
    --network-endpoint-group ${NEG_NAME} \
    --network-endpoint-group-zone ZONE \
    --balancing-mode [RATE | UTILIZATION] \
    --max-rate-per-endpoint 5
   

Routingregelzuordnung erstellen

Die Routingregelzuordnung definiert, wie Cloud Service Mesh den Traffic in Ihrem Mesh-Netzwerk weiterleitet. Im Rahmen der Routingregelzuordnung konfigurieren Sie eine virtuelle IP-Adresse (VIP) und eine Reihe zugehöriger Trafficverwaltungsregeln, z. B. hostbasiertes Routing. Wenn eine Anwendung eine Anfrage an die VIP sendet, führt der angehängte Envoy-Sidecar-Proxy die folgenden Schritte aus:

1. Fängt die Anfrage ab
2. Bewertet die Anfrage in Übereinstimmung mit den Trafficverwaltungsregeln in der URL-Zuordnung
3. Wählt einen Back-End-Dienst anhand des Hostnamens in der Anfrage aus
4. Wählt ein Back-End oder einen Endpunkt aus, der dem ausgewählten Back-End-Dienst zugeordnet ist
5. Sendet Traffic an dieses Back-End oder den Endpunkt

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 td-gke-service als Standard-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.

   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 konfiguriert Cloud Service Mesh Ihre Sidecar-Proxys so, dass sie Anfragen weiterleiten, die den Hostnamen service-test für Back-Ends von td-gke-service angeben. Dabei sind diese Back-Ends Endpunkte in der Netzwerk-Endpunktgruppe, die dem zuvor bereitgestellten Kubernetes-Testdienst zugeordnet ist.

Hinweis: Da Sie einen Standarddienst (td-gke-service) für die URL-Zuordnung konfiguriert haben, wird jede ausgehende Anfrage, die von einem Sidecar-Proxy verarbeitet wird, an die Back-Ends weitergeleitet, die diesem Standarddienst zugeordnet sind.

Konfiguration prüfen

In diesem Abschnitt wird gezeigt, wie Sie prüfen, ob der vom Busybox-Beispielclient gesendete Traffic an Ihren Kubernetes-Dienst service-test weitergeleitet wird. Zum Senden einer Testanfrage können Sie auf eine Shell in einem der Container zugreifen und den folgenden Prüfungsbefehl ausführen. Ein service-test-Pod sollte den Hostnamen des Bereitstellungs-Pods zurückgeben.

# Get the name of the pod running 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 at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

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

So wird die Konfiguration geprüft:

• Der Beispielclient hat eine Anfrage gesendet, in der der Hostname service-test angegeben ist.
• Der Beispielclient verfügt über einen Envoy-Sidecar-Proxy, der vom Envoy-Sidecar-Injektor eingefügt wurde.
• Der Sidecar-Proxy hat die Anfrage abgefangen.
• Envoy hat mithilfe der URL-Zuordnung den Hostnamen service-test mit dem Cloud Service Mesh-Dienst td-gke-service abgeglichen.
• Envoy hat einen Endpunkt aus der mit td-gke-service verknüpften Netzwerk-Endpunktgruppe ausgewählt.
• Envoy hat die Anfrage an einen Pod gesendet, der mit dem Kubernetes-Dienst service-test verknüpft ist.

Zum verwalteten Sidecar-Injektor migrieren

In dieser Anleitung erfahren Sie, wie Sie eine Anwendung vom alten Cloud Service Mesh-Sidecar-Injektor in GKE (mit einem In-Cluster-Sidecar-Injektor) zu einem mit einem verwalteten Sidecar-Injektor migrieren.

Sidecar-Injektion im Cluster deaktivieren

Mit den folgenden Befehlen wird der alte Sidecar-Injektor im Cluster für den Standard-Namespace deaktiviert.

kubectl label namespace default istio-injection-

In-Cluster-Sidecar-Injektor bereinigen

Laden Sie den alten Envoy-Sidecar-Injektor herunter und extrahieren Sie ihn.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Ressourcen für Sidecar-Injektoren im Cluster löschen

kubectl delete -f specs/

Nächste Schritte

• Weitere Informationen zur Erweiterten Trafficverwaltung.
• Weitere Informationen zur Sicherheit von Cloud Service Mesh-Diensten
• Beobachtbarkeit mit Envoy einrichten.
• Informationen zur Fehlerbehebung bei Cloud Service Mesh-Bereitstellungen
• Optionen für die Einrichtung des Google Kubernetes Engine-Pods mit automatischer Envoy-Einfügung.