Envoy-Proxy für Load-Balancing von gRPC-Diensten in GKE verwenden

In dieser Anleitung wird gezeigt, wie mehrere gRPC-Dienste, die in Google Kubernetes Engine (GKE) über eine einzelne externe IP-Adresse bereitgestellt wurden, mithilfe von Netzwerk-Load-Balancing und Envoy-Proxy verfügbar gemacht werden. Es werden einige der erweiterten Features vorgestellt, die Envoy für gRPC bietet.

Einführung

gRPC ist ein sprachunabhängiges Open-Source-RPC-Framework auf der Basis von HTTP/2, das für eine effiziente Repräsentation bei der Übertragung und eine schnelle Serialisierung Protokollzwischenspeicher nutzt. Ausgehend von Stubby, dem internen Google-RPC-Framework, ermöglicht gRPC zwischen Mikrodiensten sowie zwischen mobilen Clients und APIs eine Kommunikation mit geringer Latenz.

gRPC wird über HTTP/2 ausgeführt und bietet gegenüber HTTP/1.1 verschiedene Vorteile, z. B. eine effiziente binäre Codierung, Multiplexing von Anfragen und Antworten über eine einzelne Verbindung sowie automatische Ablaufsteuerung. Außerdem bietet gRPC verschiedene Optionen für das Load-Balancing. Der Schwerpunkt dieser Anleitung liegt auf Situationen, in denen Clients nicht vertrauenswürdig sind, z. B. bei mobilen Clients sowie Clients, die außerhalb der Vertrauensgrenze des Dienstanbieters ausgeführt werden. Von den Load-Balancing-Optionen, die gRPC bietet, verwenden Sie in dieser Anleitung das proxybasierte Load-Balancing.

In dieser Anleitung stellen Sie einen Kubernetes-Dienst mit TYPE=LoadBalancer bereit, der als Transportebene (Ebene 4) für das Netzwerk-Load-Balancing in Google Cloud verfügbar gemacht wird. Dieser Dienst stellt eine einzelne öffentliche IP-Adresse bereit und leitet TCP-Verbindungen direkt an die konfigurierten Back-Ends weiter. Das Back-End in der Anleitung ist ein Kubernetes-Deployment von Envoy-Instanzen.

Envoy ist ein Open-Source-Proxy für die Anwendungsschicht (Schicht 7), der viele erweiterte Features bietet. Sie verwenden ihn in dieser Anleitung, um SSL/TLS-Verbindungen zu beenden und gRPC-Traffic an den entsprechenden Kubernetes-Dienst weiterzuleiten. Im Vergleich zu anderen Lösungen für die Anwendungsschicht wie Kubernetes Ingress bietet die direkte Verwendung von Envoy mehrere Anpassungsoptionen, wie etwa die folgenden:

  • Diensterkennung
  • Load-Balancing-Algorithmen
  • Umwandlung von Anfragen und Antworten – zum Beispiel in JSON oder gRPC-Web
  • Authentifizierung von Anfragen durch Validierung von JWT-Tokens
  • gRPC-Systemdiagnosen

Durch Kombination von Netzwerk-Load-Balancing mit Envoy können Sie einen Endpunkt einrichten (externe IP-Adresse), der den Traffic an eine Reihe von Envoy-Instanzen weiterleitet, die in einem GKE-Cluster ausgeführt werden. Diese Instanzen verwenden dann Informationen aus der Anwendungsschicht, um Anfragen über den Proxy an verschiedene gRPC-Dienste weiterzuleiten, die im Cluster ausgeführt werden. Die Envoy-Instanzen verwenden das Cluster-DNS, um eingehende gRPC-Anfragen an die fehlerfreien, ausgeführten Pods für jeden Dienst zu identifizieren und per Load-Balancing zu verteilen. Das bedeutet, dass der Traffic nach der RPC-Anfrage und nicht nach der TCP-Verbindung vom Client per Load-Balancing an die Pods verteilt wird.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

  1. Melden Sie sich bei Ihrem Google-Konto an.

    Wenn Sie noch kein Konto haben, melden Sie sich hier für ein neues Konto an.

  2. Wählen Sie in der Cloud Console auf der Seite für die Projektauswahl ein Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  4. Cloud Build, Container Registry, and Container Analysis APIs aktivieren.

    Aktivieren Sie die APIs

Architektur

In dieser Anleitung stellen Sie zwei gRPC-Dienste, echo-grpc und reverse-grpc, in einem Google Kubernetes Engine(GKE)-Cluster bereit und machen sie über eine öffentliche IP-Adresse im Internet verfügbar. Das folgende Diagramm zeigt die Architektur, mit der diese beiden Dienste über einen einzelnen Endpunkt verfügbar gemacht werden:

Architektur zum Bereitstellen von

Das Netzwerk-Load-Balancing nimmt eingehende Anfragen aus dem Internet entgegen (z. B. von mobilen Clients oder Dienstnutzern außerhalb Ihres Unternehmens) und führt die folgenden Aufgaben aus:

  • Load-Balancing für eingehende Verbindungen zu den Worker-Knoten im Pool. Der Traffic wird an den Kubernetes-Dienst envoy weitergeleitet, der auf allen Worker-Knoten im Cluster verfügbar gemacht wird. Der Kubernetes-Netzwerkproxy leitet diese Verbindungen an Pods weiter, auf denen Envoy ausgeführt wird.
  • HTTP-Systemdiagnosen für die Worker-Knoten im Cluster.

Envoy führt die folgenden Aufgaben aus:

  • Beendigung von SSL/TLS-Verbindungen.
  • Erkennung von Pods, auf denen die gRPC-Dienste ausgeführt werden, durch Abfrage des internen DNS-Dienstes des Clusters.
  • Weiterleitung des Traffics an die gRPC-Dienst-Pods und damit verbundenes Load-Balancing.
  • Systemdiagnosen der gRPC-Dienste gemäß gRPC-Systemdiagnoseprotokoll.
  • Bereitstellung eines Endpunkts für die Systemdiagnose mithilfe von Netzwerk-Load-Balancing.

Die gRPC-Dienste (echo-grpc und reverse-grpc) werden als monitorlose Kubernetes-Dienste verfügbar gemacht. Das bedeutet, dass keine clusterIP-Adresse zugewiesen wird und der Kubernetes-Netzwerkproxy kein Load-Balancing für den Traffic zu den Pods vornimmt. Stattdessen wird im DNS-Dienst des Clusters ein DNS-A-Eintrag erstellt, der die IP-Adressen der Pods enthält. Envoy ermittelt aus diesem DNS-Eintrag die IP-Adressen der Pods und nimmt entsprechend der in Envoy konfigurierten Richtlinie das Load-Balancing vor.

Im folgenden Diagramm sind die Kubernetes-Objekte dargestellt, die in dieser Anleitung eine Rolle spielen:

In dieser Anleitung verwendete Kubernetes-Objekte, einschließlich Diensten, YAML-Dateien, DNS-A-Einträgen, Secrets, Pods und Proxyeinträgen

Umgebung initialisieren

In diesem Abschnitt legen Sie Umgebungsvariablen fest, die später in der Anleitung verwendet werden.

  1. Öffnen Sie Cloud Shell:

    Zu Cloud Shell

    Für alle Befehle in dieser Anleitung wird Cloud Shell verwendet.

  2. Rufen Sie in Cloud Shell die aktuelle Projekt-ID auf:

    gcloud config list --format 'value(core.project)'
    
  3. Wenn der Befehl nicht die ID des ausgewählten Projekts zurückgibt, konfigurieren Sie Cloud Shell für die Verwendung Ihres Projekts. Ersetzen Sie dabei project-id durch den Namen Ihres Projekts:

    gcloud config set project project-id
    
  4. Legen Sie Umgebungsvariablen für die Region und Zone fest, die Sie für diese Anleitung verwenden möchten:

    REGION=us-central1
    ZONE=$REGION-b
    

    In dieser Anleitung werden die Region us-central1 und die Zone us-central1-b verwendet. Sie können die Region und die Zone jedoch Ihren Anforderungen entsprechend ändern.

GKE-Cluster erstellen

  1. Erstellen Sie einen GKE-Cluster zum Ausführen Ihrer gRPC-Dienste:

    gcloud container clusters create grpc-cluster --zone $ZONE
    
  2. Prüfen Sie, ob der kubectl-Kontext eingerichtet wurde, indem Sie die Worker-Knoten in Ihrem Cluster auflisten:

    kubectl get nodes -o name
    

    Die Ausgabe sieht etwa so aus:

    node/gke-grpc-cluster-default-pool-c9a3c791-1kpt
    node/gke-grpc-cluster-default-pool-c9a3c791-qn92
    node/gke-grpc-cluster-default-pool-c9a3c791-wf2h
    

gRPC-Dienste bereitstellen

Wenn Sie mit einem Load-Balancer Traffic an mehrere gRPC-Dienste weiterleiten möchten, stellen Sie zwei einfache gRPC-Dienste bereit: echo-grpc und reverse-grpc. Von beiden Diensten wird eine unäre Methode verfügbar gemacht, bei der im Feld für die Inhaltsanfrage ein String verwendet wird. echo-grpc reagiert mit unverändertem Inhalt, während reverse-grpcmit dem umgekehrten Inhaltsstring antwortet.

  1. Klonen Sie das Repository mit den gRPC-Diensten und wechseln Sie zum Arbeitsverzeichnis:

    git clone https://github.com/GoogleCloudPlatform/grpc-gke-nlb-tutorial
    cd grpc-gke-nlb-tutorial
    
  2. Erstellen Sie mit Cloud Build die Container-Images für die Echo- und Reverse-gRPC-Dienste und speichern Sie sie in Container Registry:

    gcloud builds submit -t gcr.io/$GOOGLE_CLOUD_PROJECT/echo-grpc echo-grpc
    
    gcloud builds submit -t gcr.io/$GOOGLE_CLOUD_PROJECT/reverse-grpc reverse-grpc
    
  3. Überprüfen Sie, ob die Images in Container Registry vorhanden sind:

    gcloud container images list --repository gcr.io/$GOOGLE_CLOUD_PROJECT
    

    Die Ausgabe sieht etwa so aus:

    NAME
    gcr.io/grpc-gke-nlb-tutorial/echo-grpc
    gcr.io/grpc-gke-nlb-tutorial/reverse-grpc
    
  4. Erstellen Sie für echo-grpc und reverse-grpc Kubernetes-Deployments:

    sed s/GOOGLE_CLOUD_PROJECT/$GOOGLE_CLOUD_PROJECT/ \
        k8s/echo-deployment.yaml | kubectl apply -f -
    
    sed s/GOOGLE_CLOUD_PROJECT/$GOOGLE_CLOUD_PROJECT/ \
        k8s/reverse-deployment.yaml | kubectl apply -f -
    
  5. Überprüfen Sie, ob für jedes Deployment zwei Pods verfügbar sind:

    kubectl get deployments
    

    Die Ausgabe sieht ungefähr so aus: Die Werte für DESIRED, CURRENT, UP-TO-DATE und AVAILABLE sollten für beide Deployments 2 sein.

    NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    echo-grpc      2         2         2            2           1m
    reverse-grpc   2         2         2            2           1m
    
  6. Erstellen Sie monitorlose Kubernetes-Dienste für echo-grpc und reverse-grpc. Mit diesen Befehlen werden DNS-A-Einträge im DNS-Dienst des Clusters erstellt, aber keine virtuellen IP-Adressen zugewiesen.

    kubectl apply -f k8s/echo-service.yaml
    kubectl apply -f k8s/reverse-service.yaml
    
  7. Prüfen Sie, ob sowohl echo-grpc als auch reverse-grpc als Kubernetes-Dienste vorhanden sind:

    kubectl get services
    

    Die Ausgabe sieht ungefähr so aus: Sowohl für echo-grpc als auch für reverse-grpc sollten TYPE=ClusterIP und CLUSTER-IP=None festgelegt sein.

    NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
    echo-grpc      ClusterIP   None         <none>        8081/TCP   35s
    kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    47m
    reverse-grpc   ClusterIP   None         <none>        8082/TCP   21s
    

Netzwerk-Load-Balancing einrichten

  1. Erstellen Sie in Ihrem Cluster einen Kubernetes-Dienst vom Typ LoadBalancer:

    kubectl apply -f k8s/envoy-service.yaml
    

    Mit diesem Befehl werden die für das Netzwerk-Load-Balancing erforderlichen Ressourcen bereitgestellt und es wird eine sitzungsspezifische öffentliche IP-Adresse zugewiesen. Das Zuweisen der öffentlichen IP-Adresse kann einige Minuten in Anspruch nehmen.

  2. Führen Sie den folgenden Befehl aus und warten Sie, bis sich der Wert für EXTERNAL-IP für den Dienst envoy von <pending> in eine öffentliche IP-Adresse ändert:

    kubectl get services envoy --watch
    
  3. Drücken Sie Control+C, wenn Sie nicht mehr warten möchten.

Selbstsigniertes SSL/TLS-Zertifikat erstellen

Envoy verwendet ein Zertifikat und einen Schlüssel, wenn SSL/TLS-Verbindungen beendet werden. Sie erstellen zuerst ein selbstsigniertes SSL/TLS-Zertifikat.

  1. Erstellen Sie eine Umgebungsvariable, um die öffentliche IP-Adresse des Envoy-Dienstes zu speichern, den Sie im vorangegangenen Abschnitt erstellt haben:

    EXTERNAL_IP=$(kubectl get service envoy -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    
  2. Erstellen Sie ein selbstsigniertes SSL/TLS-Zertifikat und einen Schlüssel:

    openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
        -keyout privkey.pem -out cert.pem -subj "/CN=$EXTERNAL_IP"
    
  3. Erstellen Sie ein Kubernetes-TLS-Secret mit dem Namen envoy-certs, das das selbstsignierte SSL/TLS-Zertifikat und den Schlüssel enthält:

    kubectl create secret tls envoy-certs \
        --key privkey.pem --cert cert.pem \
        --dry-run -o yaml | kubectl apply -f -
    

Envoy bereitstellen

  1. Erstellen Sie eine Kubernetes-ConfigMap zum Speichern der Envoy-Konfigurationsdatei (envoy.yaml):

    kubectl apply -f k8s/envoy-configmap.yaml
    
  2. Erstellen Sie ein Kubernetes-Deployment für Envoy:

    kubectl apply -f k8s/envoy-deployment.yaml
    
  3. Prüfen Sie, ob zwei envoy-Pods ausgeführt werden:

    kubectl get deployment envoy
    

    Die Ausgabe sieht etwa so aus:

    NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    envoy     2         2         2            2           1m
    

Nun können Sie die gRPC-Dienste testen.

gRPC-Dienste testen

Zum Testen der Dienste verwenden Sie das grpcurl-Befehlszeilentool.

  1. Installieren Sie grpcurl in Cloud Shell:

    go get github.com/fullstorydev/grpcurl
    go install github.com/fullstorydev/grpcurl/cmd/grpcurl
    
  2. Senden Sie eine Anfrage an den Echo-gRPC-Dienst:

    grpcurl -d '{"content": "echo"}' -proto echo-grpc/api/echo.proto \
        -insecure -v $EXTERNAL_IP:443 api.Echo/Echo
    

    Die Ausgabe sieht etwa so aus:

    Resolved method descriptor:
    rpc Echo ( .api.EchoRequest ) returns ( .api.EchoResponse );
    
    Request metadata to send:
    (empty)
    
    Response headers received:
    content-type: application/grpc
    date: Wed, 27 Feb 2019 04:40:19 GMT
    hostname: echo-grpc-5c4f59c578-wcsvr
    server: envoy
    x-envoy-upstream-service-time: 0
    
    Response contents:
    {
      "content": "echo"
    }
    
    Response trailers received:
    (empty)
    Sent 1 request and received 1 response
    

    Im Antwortheader hostname ist der Name des Pods echo-grpc zu sehen, der die Anfrage verarbeitet hat. Wenn Sie den Befehl einige Male wiederholen, sollten Sie zwei unterschiedliche Werte für den Antwortheader hostname sehen, die den Namen der echo-grpc-Pods entsprechen.

  3. Überprüfen Sie das entsprechende Verhalten für den Reverse-gRPC-Dienst:

    grpcurl -d '{"content": "reverse"}' -proto reverse-grpc/api/reverse.proto \
        -insecure -v $EXTERNAL_IP:443 api.Reverse/Reverse
    

    Die Ausgabe sieht etwa so aus:

    Resolved method descriptor:
    rpc Reverse ( .api.ReverseRequest ) returns ( .api.ReverseResponse );
    
    Request metadata to send:
    (empty)
    
    Response headers received:
    content-type: application/grpc
    date: Wed, 27 Feb 2019 04:45:56 GMT
    hostname: reverse-grpc-74cdc4849f-tvsfb
        server: envoy
    x-envoy-upstream-service-time: 2
    
    Response contents:
    {
      "content": "esrever"
    }
    
    Response trailers received:
    (empty)
    Sent 1 request and received 1 response
    

Fehlerbehebung

Wenn Sie Probleme mit dieser Anleitung haben, empfehlen wir Ihnen, die folgenden Dokumente zu lesen:

Außerdem können Sie die Verwaltungsoberfläche von Envoy nutzen, um Probleme mit der Envoy-Konfiguration zu diagnostizieren.

  1. Stellen Sie zum Öffnen der Verwaltungsoberfläche die Portweiterleitung von Cloud Shell auf den admin-Port eines der Envoy-Pods ein:

    kubectl port-forward \
        $(kubectl get pods -o name | grep envoy | head -n1) 8080:8090
    
  2. Warten Sie, bis Sie in der Console diese Ausgabe sehen:

    Forwarding from 127.0.0.1:8080 -> 8090
    
  3. Klicken Sie in Cloud Shell auf die Schaltfläche Webvorschau und wählen Sie Preview on port 8080 (Vorschau auf Port 8080) aus. Es wird ein neues Browserfenster mit der Verwaltungsoberfläche angezeigt.

    Envoy-Verwaltungsoberfläche mit ausgewählter Vorschau

  4. Wenn Sie fertig sind, wechseln Sie zu Cloud Shell zurück und drücken Sie Control+C, um die Portweiterleitung zu beenden.

Alternative Möglichkeiten zur Weiterleitung von gRPC-Traffic

Diese Lösung können Sie auf verschiedene Arten an Ihre Umgebung anpassen.

Alternative Load-Balancer für die Anwendungsschicht

Einige der Funktionen, die Envoy für die Anwendungsschicht bietet, können auch von anderen Load-Balancing-Lösungen ausgeführt werden:

  • Mit einem Kubernetes-Ingress-Objekt können Sie HTTP(S)-Load-Balancing konfigurieren und dieses anstelle von Netzwerk-Load-Balancing und Envoy verwenden. Die Verwendung von HTTP(S)-Load-Balancing bietet gegenüber Netzwerk-Load-Balancing verschiedene Vorteile, z. B. verwaltete SSL/TLS-Zertifikate und Integration in andere Google Cloud-Produkte wie Cloud CDN und Cloud IAP.

    Es wird empfohlen, HTTP(S)-Load-Balancing zu verwenden, wenn Sie keine Unterstützung für folgende Aufgaben benötigen:

    • gRPC-Systemdiagnosen
    • Präzise Steuerung des Load-Balancing-Algorithmus
    • Bereitstellung von mehr als 50 Diensten

    Weitere Informationen zum Bereitstellen von HTTP(S)-Load-Balancing mit einem gRPC-Beispieldienst finden Sie in der Google Kubernetes Engine-Dokumentation zu Ingress und der Anleitung GKE gRPC Ingress LoadBalancing auf GitHub.

  • Wenn Sie Istio verwenden, können Sie die darin enthaltenen Features verwenden, um gRPC-Traffic weiterzuleiten und das zugehörige Load-Balancing vorzunehmen. Das Ingress-Gateway von Istio wird für das Netzwerk-Load-Balancing mit einem Envoy-Back-End bereitgestellt, ähnlich wie bei der Architektur in dieser Anleitung. Der Hauptunterschied besteht darin, dass der Envoy-Proxy über die Objekte zur Traffic-Weiterleitung von Istio konfiguriert wird. Damit die Beispieldienste in dieser Anleitung im Service Mesh von Istio routingfähig sind, müssen Sie die Zeile clusterIP: None aus den Kubernetes-Dienstmanifesten (echo-service.yaml und reverse-service.yaml) entfernen. Wenn Sie bereits Istio verwenden, empfehlen wir zur Weiterleitung an Ihre gRPC-Dienste die Verwendung des Ingress-Gateways.

  • Sie können NGINX anstelle von Envoy verwenden, entweder als Deployment oder mit dem NGINX-Ingress-Controller für Kubernetes. In dieser Anleitung wird Envoy verwendet, da es fortschrittliche gRPC-Funktionen bietet, z. B. Unterstützung für das gRPC-Systemdiagnoseprotokoll.

  • Sie können Ambassador und Contour verwenden, die Kubernetes-Ingress-Controller bereitstellen und auf Envoy basieren.

  • Sie können Voyager verwenden, einen Kubernetes-Ingress-Controller, der auf HAProxy basiert.

Interne VPC-Netzwerkverbindung

Wenn Sie die Dienste außerhalb Ihres GKE-Clusters, jedoch nur innerhalb Ihres VPC-Netzwerks verfügbar machen möchten, können Sie statt Netzwerk-Load-Balancing internes TCP/UDP-Load-Balancing verwenden. Fügen Sie dazu dem Manifest envoy-service.yaml die Annotation cloud.google.com/load-balancer-type: "Internal" hinzu.

Envoy-Deployment und DaemonSet im Vergleich

In dieser Anleitung wird Envoy als Kubernetes-Deployment konfiguriert. Diese Konfiguration hat zur Folge, dass die Anzahl der Envoy-Pods durch die Einstellung replica im Deployment-Manifest bestimmt wird. Wenn der Load-Balancer eingehende Anforderungen an einen Worker-Knoten weiterleitet, auf dem kein Envoy-Pod ausgeführt wird, leitet der Kubernetes-Netzwerkproxy die Anfrage an einen Worker-Knoten weiter, auf dem ein Envoy-Pod ausgeführt wird.

DaemonSet ist eine Alternative zum Deployment für Envoy. Mit einem DaemonSet wird auf jedem Worker-Knoten im GKE-Cluster ein Envoy-Pod ausgeführt. Bei dieser Alternative ist die Ressourcennutzung in großen Clustern (mehr Envoy-Pods) höher. Andererseits erreichen eingehende Anfragen immer einen Worker-Knoten, auf dem ein Envoy-Pod ausgeführt wird. Dies hat einen geringeren Netzwerk-Traffic in Ihrem Cluster sowie eine niedrigere durchschnittliche Latenz zur Folge, da Anfragen nicht zwischen Worker-Knoten weitergeleitet werden müssen, damit ein Envoy-Pod erreicht wird.

Bereinigen

Nachdem Sie die aktuelle Anleitung abgeschlossen haben, können Sie die in Google Cloud erstellten Ressourcen bereinigen, damit sie keine kostenpflichtigen Kontingente verbrauchen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

  1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite "Ressourcen verwalten"

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen .
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Google Cloud-Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen:

  1. Löschen Sie den lokalen Git-Repository-Klon in Cloud Shell:

    cd ; rm -rf ~/grpc-gke-nlb-tutorial
    
  2. Löschen Sie die Images in Container Registry:

    gcloud container images list-tags gcr.io/$GOOGLE_CLOUD_PROJECT/echo-grpc \
        --format 'value(digest)' | xargs -I {} gcloud container images delete \
        --force-delete-tags --quiet gcr.io/$GOOGLE_CLOUD_PROJECT/echo-grpc@sha256:{}
    
    gcloud container images list-tags gcr.io/$GOOGLE_CLOUD_PROJECT/reverse-grpc \
        --format 'value(digest)' | xargs -I {} gcloud container images delete \
        --force-delete-tags --quiet gcr.io/$GOOGLE_CLOUD_PROJECT/reverse-grpc@sha256:{}
    
  3. Löschen Sie den Google Kubernetes Engine-Cluster:

    gcloud container clusters delete grpc-cluster --zone $ZONE --quiet  --async
    

Weitere Informationen