HTTP/2 für Load-Balancing mit Ingress verwenden

Diese Seite zeigt, wie Sie mit Ingress- und Dienstobjekten von Kubernetes einen externen HTTP(S)-Load-Balancer konfigurieren können, um über HTTP/2 mit Back-End-Diensten zu kommunizieren. Diese Funktion ist ab Google Kubernetes Engine-Version 1.11.2 verfügbar.

Überblick

Ein HTTP(S)-Load-Balancer fungiert als Proxy zwischen Ihren Clients und Ihrer Anwendung. Clients können HTTP/1.1 oder HTTP/2 verwenden, um mit dem Load-Balancer-Proxy zu kommunizieren. Für die Verbindung vom Load-Balancer-Proxy zu Ihrer Anwendung wird jedoch standardmäßig HTTP/1.1 verwendet. Wenn Ihre in einem Google Kubernetes Engine-Pod ausgeführte Anwendung HTTP/2-Anfragen empfangen kann, konfigurieren Sie den externen Load-Balancer so, dass bei der Weiterleitung von Anfragen an die Anwendung HTTP/2 verwendet wird.

Diagramm mit HTTP/2-Verbindung vom Load-Balancer zum Pod (zum Vergrößern klicken)

In dieser Übung erstellen Sie ein Deployment, einen Dienst und eine Ingress-Ressource. Mit einer cloud.google.com/app-protocols-Annotation in Ihrem Dienstmanifest geben Sie an, dass der Load-Balancer für die Kommunikation mit Ihrer Anwendung HTTP/2 verwenden soll. Dann rufen Sie den Dienst auf und prüfen, ob Ihre Anwendung eine HTTP/2-Anfrage erhalten hat.

Vorbereitung

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

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest:
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Deployment erstellen

In diesem Deployment-Manifest wird festgelegt, dass Sie zwei Replikate der Webanwendung echoheaders ausführen möchten:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoheaders
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echoheaders
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - name: echoheaders
        image: k8s.gcr.io/echoserver:1.10
        ports:
        - containerPort: 8443

Kopieren Sie das Manifest in eine Datei mit dem Namen my-deployment.yaml und erstellen Sie das Deployment:

kubectl apply -f my-deployment.yaml

Dienst erstellen

Dies ist ein Manifest für den Dienst:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
  name: echoheaders
  labels:
    app: echoheaders
spec:
  type: NodePort
  ports:
  - port: 443
    targetPort: 8443
    protocol: TCP
    name: my-port
  selector:
    app: echoheaders

Speichern Sie das Manifest in einer Datei mit dem Namen my-service.yaml und erstellen Sie den Dienst:

kubectl apply -f my-service.yaml

Lassen Sie den Service anzeigen:

kubectl get service echoheaders --output yaml

Die Ausgabe sieht etwa so aus:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
    ...
  labels:
    app: echoheaders
  name: echoheaders
  ...
spec:
  clusterIP: 10.39.251.148
  ...
  ports:
  - name: my-port
    nodePort: 30647
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: echoheaders
  ...
  type: NodePort
...

Für diese Übung sollten Sie die folgenden wichtigen Punkte in Bezug auf Ihren Dienst beachten:

  • Der Dienst hat den Typ NodePort. Dies ist der erforderliche Typ für Dienste, die einem Ingress zugeordnet werden.

  • Jeder Pod mit dem Label app: echoheaders ist ein Mitglied des Dienstes. Dies wird durch das Feld selector angegeben.

  • Der Dienst hat einen Port mit dem Namen my-port. Die Annotation cloud.google.com/app-protocols gibt an, dass my-port das HTTP/2-Protokoll verwenden soll.

  • Der über TCP-Port 443 an den Dienst gerichtete Traffic wird in einem der Mitglieds-Pods an TCP-Port 8443 weitergeleitet. Dies wird durch die Felder port und targetPort angegeben.

Ingress-Ressource erstellen

Dies ist ein Manifest für das Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echomap
spec:
  backend:
    serviceName: echoheaders
    servicePort: 443

Kopieren Sie das Manifest in eine Datei mit dem Namen my-ingress.yaml und erstellen Sie das Ingress-Objekt:

kubectl apply -f my-ingress.yaml

Warten Sie einige Minuten, bis der Kubernetes-Ingress-Controller einen HTTP(S)-Load-Balancer konfiguriert hat, und rufen Sie anschließend das Ingress auf:

kubectl get ingress echomap --output yaml

Die Ausgabe sieht etwa so aus:

kind: Ingress
metadata:
  ...
  name: echomap
  ...
spec:
  backend:
    serviceName: echoheaders
    servicePort: 443
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.2

Beachten für diese Übung die folgenden wichtigen Punkte in Bezug auf Ihr Ingress:

  • Die IP-Adresse für eingehenden Traffic wird unter loadBalancer:ingress aufgeführt.

  • Eingehende Anfragen werden an einen Pod weitergeleitet, der Mitglied des Dienstes echoheaders ist. In dieser Übung haben die Mitglieds-Pods das Label app: echoheaders.

  • Anfragen werden an den Zielport des Pods weitergeleitet, der im echoheaders-Dienstmanifest angegeben ist. In dieser Übung lautet der Pod-Zielport 8443.

Unterstützung von HTTP/2 durch Load-Balancer prüfen

gcloud

  1. Listen Sie die Back-End-Dienste auf:

    gcloud compute backend-services list
    
  2. Ihren Back-End-Dienst beschreiben:

    gcloud beta compute backend-services describe backend-service-name --global
    

    Dabei ist backend-service-name der Name Ihres Back-End-Dienstes.

  3. Prüfen Sie in der Ausgabe, ob das Protokoll HTTP/2 ist:

    backends:
    ...
    description: '{...,"kubernetes.io/service-port":"443","x-features":["HTTP2"]}'
    ...
    kind: compute#backendService
    loadBalancingScheme: EXTERNAL
    protocol: HTTP2
    ...
    

Console

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".

    Zur Seite „Load-Balancing“

  2. Suchen Sie unter Name nach Ihrem Load-Balancer.

    Screenshot des HTTP-Load-Balancers in der Google Cloud Console (zum Vergrößern klicken)
  3. Klicken Sie auf den Namen Ihres Load-Balancers, um den Back-End-Dienst aufzurufen.

  4. Prüfen Sie, ob das Endpoint protocol (Endpunktprotokoll) für Ihren Back-End-Dienst HTTP/2 ist.

    Screenshot des HTTP/2-Back-End-Dienstes in der Google Cloud Console (zum Vergrößern klicken)

Dienst aufrufen

Warten Sie einige Minuten, bis der Load-Balancer und der Back-End-Dienst konfiguriert wurden. Geben Sie die externe IP-Adresse des Load-Balancers in die Adressleiste Ihres Browsers ein.

Die Ausgabe zeigt Informationen zur Anfrage vom Load-Balancer an den Pod:

Hostname: echoheaders-7886d5bc68-xnrwj
...
Request Information:
  ...
  method=GET
  real path=/
  query=
  request_version=2
  request_scheme=https
  ...

Request Headers:
  ...
  x-forwarded-for=[YOUR_IP_ADDRESS], 203.0.113.2
  x-forwarded-proto=http
...

Für diese Übung sollten Sie die folgenden wichtigen Punkte in Bezug auf die obige Ausgabe beachten:

  • Die Zeile request_version=2 zeigt an, dass für die Anfrage zwischen dem Load-Balancer und dem Pod HTTP/2 verwendet wurde.

  • Die Zeile x-forwarded-proto=http zeigt an, dass für die Anfrage zwischen Ihnen und dem Load-Balancer HTTP 1.1 und nicht HTTP/2 verwendet wurde.

Nächste Schritte