Maglev-Load-Balancing in GKE Dataplane V2 verwenden

In diesem Dokument wird beschrieben, wie Sie Maglev-Load-Balancing für Dienste in GKE Dataplane V2 konfigurieren und überprüfen.

Maglev ist ein Algorithmus für konsistentes Hashing, der Load-Balancing mit hohem Durchsatz und niedriger Latenz bietet. Maglev minimiert Paketverluste und Verbindungsunterbrechungen, wenn Backend-Pods skaliert, aktualisiert oder neu geplant werden. So wird dafür gesorgt, dass derselbe Flow immer demselben Backend zugeordnet wird.

Weitere Informationen finden Sie im Maglev-Consistent-Hashing-Algorithmus.

Wir empfehlen diese Funktion für Arbeitslasten mit langlebigen Verbindungen oder zustandsorientierte Anwendungen, bei denen Backend-Änderungen bestehende Abläufe nicht unterbrechen dürfen.

Informationen zum Ressourcen-Overhead und zu Skalierbarkeitsaspekten finden Sie unter GKE Dataplane V2-Konzepte.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Voraussetzungen und Einschränkungen

• GKE-Version:1.36.0-gke.2882000 und höher
• GKE Dataplane V2: aktiviert
• Clustermodi: Autopilot und Standard

GKE-Cluster mit GKE Dataplane V2 erstellen

Damit Sie Maglev verwenden können, benötigen Sie einen GKE-Cluster mit aktiviertem GKE Dataplane V2.

gcloud container clusters create-auto CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --release-channel=rapid
gcloud container clusters get-credentials CLUSTER_NAME \
    --region=COMPUTE_REGION

gcloud container clusters create CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --enable-dataplane-v2 \
    --cluster-version=1.36.0-gke.2882000
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE

Backend-Anwendung bereitstellen

Bevor Sie Ihre Load-Balancing-Dienste konfigurieren, müssen Sie eine Backend-Anwendung bereitstellen, die den Traffic verarbeitet. In diesem Deployment werden fünf Replikate der hello-app-Beispielanwendung ausgeführt.

1. Speichern Sie das folgende Manifest als echo-backend.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: echo-backend
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: echo-backend
     template:
       metadata:
         labels:
           app: echo-backend
       spec:
         containers:
         - name: hello
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
           ports:
           - containerPort: 8080
   

2. Wenden Sie das Manifest an:

   kubectl apply -f echo-backend.yaml
   

Load-Balancing-Dienste konfigurieren

Sie können Services so konfigurieren, dass entweder der Maglev-Load-Balancing-Algorithmus oder der standardmäßige zufällige Load-Balancing-Algorithmus verwendet wird. Beide Dienste sind auf das Deployment echo-backend ausgerichtet, das im vorherigen Schritt erstellt wurde.

Maglev-Dienst konfigurieren

Wenn Sie Maglev-Load-Balancing aktivieren möchten, fügen Sie bei der Erstellung den Dienstmetadaten die Annotation gke.networking.io/lb-algorithm: "maglev" hinzu.

1. Speichern Sie das folgende Manifest als maglev-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: maglev-service
     annotations:
       gke.networking.io/lb-algorithm: "maglev"
   spec:
     selector:
       app: echo-backend
     ports:
       - protocol: TCP
         port: 80
         targetPort: 8080
   

2. Wenden Sie das Manifest an:

   kubectl apply -f maglev-service.yaml
   

Zufälligen Dienst konfigurieren

Standardmäßig verwenden Dienste einen zufälligen Load-Balancing-Algorithmus. Sie müssen keine Annotation angeben, um den Standardalgorithmus zu verwenden. Im folgenden Beispiel wird er jedoch explizit konfiguriert, um ihn mit anderen Algorithmen vergleichen zu können.

1. Speichern Sie das folgende Manifest als random-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: random-service
     annotations:
       gke.networking.io/lb-algorithm: "random"
   spec:
     selector:
       app: echo-backend
     ports:
       - protocol: TCP
         port: 80
         targetPort: 8080
   

2. Wenden Sie das Manifest an:

   kubectl apply -f random-service.yaml
   

Traffickonsistenz prüfen

Sie können die Unterschiede bei der Routing-Konsistenz zwischen Maglev und zufälligem Load-Balancing überprüfen, indem Sie Testclient-Pods bereitstellen, die Traffic von einem festen Quellport senden.

Maglev-Traffic-Konsistenz prüfen

Maglev leitet Anfragen vom selben Quellport konsistent an denselben Backend-Pod weiter.

1. Speichern Sie das folgende Manifest als client-maglev.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: client-maglev
   spec:
     restartPolicy: Never
     containers:
     - name: curl
       image: curlimages/curl:8.2.0
       command: ["/bin/sh", "-c"]
       args:
       - |
         while true; do
           curl -s -H "Connection: close" http://maglev-service:80 --local-port 54321 | grep Hostname
           sleep 0.5
         done
   

   Das Flag --local-port erzwingt den Quellport und der Header Connection: close trägt dazu bei, dass der Client den Quellport sofort für nachfolgende Anfragen wiederverwenden kann.

2. Wenden Sie das Manifest an:

   kubectl apply -f client-maglev.yaml
   

3. Prüfen Sie die Logs, während der Pod ausgeführt wird:

   kubectl logs client-maglev
   

   Erwartete Ausgabe:

   In der Ausgabe wird derselbe Hostname wiederholt ausgegeben. Das bedeutet, dass der gesamte Traffic vom Client konsistent an denselben Backend-Pod weitergeleitet wird:

   Hostname: echo-backend-5c78f66dbf-abcde
   Hostname: echo-backend-5c78f66dbf-abcde
   

Standardmäßige (zufällige) Traffic-Verteilung prüfen

Der Standarddienst verteilt den Traffic vom selben Quellport auf verschiedene Backend-Pods.

1. Speichern Sie das folgende Manifest als client-random.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: client-random
   spec:
     restartPolicy: Never
     containers:
     - name: curl
       image: curlimages/curl:8.2.0
       command: ["/bin/sh", "-c"]
       args:
       - |
         while true; do
           curl -s -H "Connection: close" http://random-service:80 --local-port 54321 | grep Hostname
           sleep 0.5
         done
   

2. Wenden Sie das Manifest an:

   kubectl apply -f client-random.yaml
   

3. Prüfen Sie die Logs, während der Pod ausgeführt wird:

   kubectl logs client-random
   

   Erwartete Ausgabe:

   Die Ausgabe zeigt mehrere unterschiedliche Hostnamen, was darauf hindeutet, dass der Traffic auf verschiedene Pods verteilt wird:

   Hostname: echo-backend-5c78f66dbf-abcde
   Hostname: echo-backend-5c78f66dbf-fghij
   Hostname: echo-backend-5c78f66dbf-klmno
   ...
   

Bereinigen

Führen Sie die folgenden Befehle aus, um die in dieser Anleitung verwendeten Ressourcen zu bereinigen:

1. Löschen Sie die Client-Pods, -Dienste und das Deployment:

   kubectl delete service maglev-service random-service
   kubectl delete deployment echo-backend
   kubectl delete pod client-maglev client-random
   

2. Löschen Sie die GKE-Cluster:

gcloud container clusters delete CLUSTER_NAME --region=COMPUTE_REGION

gcloud container clusters delete CLUSTER_NAME --zone=COMPUTE_ZONE