Containernatives Load-Balancing über Ingress

Autopilot Standard

Auf dieser Seite wird erläutert, wie Sie containernatives Load-Balancing in Google Kubernetes Engine (GKE) verwenden. Containernatives Load-Balancing ermöglicht es Load-Balancern, Pods direkt anzusteuern und Traffic gleichmäßig auf Pods zu verteilen.

Weitere Informationen zu den Vorteilen, Anforderungen und Einschränkungen des containernativen Load-Balancing finden Sie unter Containernatives Load-Balancing.

Hinweise

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 diesen Task 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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

• Prüfen Sie, ob Sie einen vorhandenen VPC-nativer Cluster haben. Erstellen Sie einen Cluster, falls erforderlich. GKE-Cluster sind standardmäßig VPC-nativ.

Containernatives Load-Balancing verwenden

In den folgenden Abschnitten werden Sie Schritt für Schritt durch die Konfiguration eines containernativen Load-Balancings in GKE geführt.

Deployment erstellen

Im folgenden Beispiel-Deployment (neg-demo-app) wird eine einzelne Instanz eines containerisierten HTTP-Servers ausgeführt. Wir empfehlen Ihnen, Arbeitslasten zu verwenden, bei denen Pod-Bereitschaftsfeedback zum Einsatz kommt.

Mithilfe von Pod-Bereitschaftsfeedback

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
        ports:
        - containerPort: 9376
          protocol: TCP
  

Mithilfe von hartcodierter Verzögerung

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
      # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
      # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
  

In diesem Deployment führt jeder Container einen HTTP-Server aus. Der HTTP-Server gibt den Hostnamen des Anwendungsservers (den Namen des Pods, auf dem der Server ausgeführt wird) als Antwort zurück.

Speichern Sie dieses Manifest als neg-demo-app.yaml und erstellen Sie dann das Deployment:

kubectl apply -f neg-demo-app.yaml

Dienst für einen containernativen Load Balancer erstellen

Nachdem Sie ein Deployment erstellt haben, müssen Sie die zugehörigen Pods in einem Dienst zusammenfassen.

Der folgende Beispieldienst neg-demo-svc zielt auf das im vorangegangenen Abschnitt erstellte Beispiel-Deployment ab:

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
spec: # Service's specification
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - name: http
    port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

Hinweis: Der Dienst wird auf Port 80 bereitgestellt und leitet den Traffic an Port 9376, den targetPort, weiter. Der targetPort entspricht in einem Bereitstellungs-Pod einem containerPort. Es ist auch möglich, einen Dienst vom Typ NodePort mit containernativem Load-Balancing zu verwenden. Ein Dienst vom Typ ClusterIP wird empfohlen, es sei denn, Sie benötigen explizit den von einem NodePort-Dienst bereitgestellten nodePort. LoadBalancer-Dienste werden nicht als Ingress-Back-Ends unterstützt.

Der Load-Balancer wird jedoch erst erstellt, wenn Sie für den Dienst eine Ingress-Ressource erstellen.

Speichern Sie dieses Manifest als neg-demo-svc.yaml und erstellen Sie dann den Dienst:

kubectl apply -f neg-demo-svc.yaml

Ingress für den Dienst erstellen

Die folgende exemplarische Ingress-Ressource neg-demo-ing steuert den von Ihnen erstellten Dienst an:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  defaultBackend:
    service:
      name: neg-demo-svc # Name of the Service targeted by the Ingress
      port:
        number: 80 # Should match the port used by the Service

Speichern Sie dieses Manifest als neg-demo-ing.yaml und erstellen Sie dann die Ingress-Ressource:

kubectl apply -f neg-demo-ing.yaml

Beim Erstellen der Ingress-Ressource wird im Projekt ein Application Load Balancer erstellt. Außerdem werden in jeder Zone, in der der Cluster ausgeführt wird, Netzwerk-Endpunktgruppen (NEGs) erstellt. Die Endpunkte in der NEG und die Endpunkte des Dienstes werden synchronisiert.

Ingress prüfen

Nachdem Sie eine Arbeitslast bereitgestellt, die Pods in einem Dienst zusammengefasst und eine Ingress-Ressource für den Dienst erstellt haben, sollten Sie prüfen, ob die Ingress-Ressource den containernativen Load-Balancer erfolgreich bereitgestellt hat.

Rufen Sie den Status des Ingress ab:

kubectl describe ingress neg-demo-ing

Die Ausgabe enthält die Ereignisse ADD und CREATE:

Events:
Type     Reason   Age                From                     Message
----     ------   ----               ----                     -------
Normal   ADD      16m                loadbalancer-controller  default/neg-demo-ing
Normal   Service  4s                 loadbalancer-controller  default backend set to neg-demo-svc:32524
Normal   CREATE   2s                 loadbalancer-controller  ip: 192.0.2.0

Load-Balancer testen

In den folgenden Abschnitten wird erläutert, wie Sie die Funktionalität eines containernativen Load-Balancers testen können.

Ingress-IP-Adresse aufrufen

Warten Sie einige Minuten, bis der Application Load Balancer konfiguriert ist.

Sie können die Funktion des containernativen Load-Balancers durch Aufruf der IP-Adresse des Ingress prüfen.

Führen Sie den folgenden Befehl aus, um die Ingress-IP-Adresse abzurufen:

kubectl get ingress neg-demo-ing

In der Befehlsausgabe wird die IP-Adresse des Ingress in der Spalte ADDRESS angezeigt. Rufen Sie in einem Webbrowser die IP-Adresse auf.

Systemstatus des Backend-Diensts prüfen

Sie können auch den Systemstatus des Backend-Diensts des Load-Balancers abrufen.

1. Dazu müssen Sie zuerst eine Liste der Backend-Dienste abrufen, die in Ihrem Projekt ausgeführt werden:

   gcloud compute backend-services list
   

   Notieren Sie sich den Namen des Backend-Dienstes, der den Namen des Dienstes enthält, z B. neg-demo-svc.

2. Dann rufen Sie den Systemstatus des Backend-Diensts ab:

   gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global
   

   Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Backend-Dienstes.

Ingress-Objekt testen

Eine weitere Möglichkeit, um zu testen, ob der Load Balancer wie erwartet funktioniert, besteht darin, das Beispiel-Deployment zu skalieren und Testanfragen an den Ingress zu senden. Anschließend überprüfen Sie, ob die Anzahl der Replikatantworten stimmt.

1. Skalieren Sie das neg-demo-app-Deployment von einer Instanz auf zwei Instanzen:

   kubectl scale deployment neg-demo-app --replicas 2
   

   Die Ausführung dieses Befehls kann mehrere Minuten dauern.

2. Prüfen Sie, ob die Einführung abgeschlossen ist:

   kubectl get deployment neg-demo-app
   

   Die Ausgabe sollte zwei verfügbare Replikate enthalten:

   NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   neg-demo-app   2         2         2            2           26m
   

3. Rufen Sie die Ingress-IP-Adresse ab:

   kubectl describe ingress neg-demo-ing
   

   Wenn dieser Befehl einen 404-Fehler zurückgibt, warten Sie einige Minuten, bis der Load Balancer gestartet wurde. Versuchen Sie es dann noch einmal.

4. Zählen Sie die Anzahl unterschiedlicher Antworten vom Load Balancer:

   for i in `seq 1 100`; do \
     curl --connect-timeout 1 -s IP_ADDRESS && echo; \
   done  | sort | uniq -c
   

   Ersetzen Sie IP_ADDRESS durch die IP-Adresse der Ingress-Ressource.

   Die Ausgabe sieht in etwa so aus:

   44 neg-demo-app-7f7dfd7bc6-dcn95
   56 neg-demo-app-7f7dfd7bc6-jrmzf
   

   In dieser Ausgabe entspricht die Anzahl der unterschiedlichen Antworten der Anzahl der Replikate, was darauf hinweist, dass alle Backend-Pods Traffic verarbeiten.

Bereinigen

Wenn Sie mit den Aufgaben auf dieser Seite fertig sind, entfernen Sie die Ressourcen anhand der folgenden Schritte, sodass keine unerwünschten Kosten für Ihr Konto entstehen:

Cluster löschen

gcloud

gcloud container clusters delete neg-demo-cluster

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie neg-demo-cluster aus und klicken Sie auf Löschen.

3. Wenn Sie zur Bestätigung aufgefordert werden, klicken Sie auf Löschen.

Nächste Schritte

• Informationen zum containernativen Load-Balancing über eigenständige zonale NEGs
• Mehr über VPC-native Cluster erfahren
• Weitere Informationen zur Ingress-Konfiguration
• Von Google verwaltete SSL-Zertifikate verwenden