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

Diese Seite zeigt, wie Sie mit Ingress- und Dienstobjekten von Kubernetes einen externen Application Load Balancer konfigurieren können, um über HTTP/2 mit Backend-Diensten zu kommunizieren.

Übersicht

Ein externer Application 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 Ihre Anwendung HTTP/2 verwendet wird.

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:

  • 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 gcloud components update ab.

Deployment erstellen

  1. Kopieren Sie dann das folgende Manifest in eine Datei mit dem Namen my-deployment.yaml.

    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: registry.k8s.io/echoserver:1.10
        ports:
        - containerPort: 8443

    Dieses Manifest beschreibt ein Deployment mit zwei Replikaten der Webanwendung echoheaders.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-deployment.yaml

Dienst erstellen

  1. Kopieren Sie dann das folgende Manifest in eine Datei mit dem Namen my-service.yaml.

    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

    Dieses Manifest beschreibt einen Service mit folgenden Attributen:

    • type: NodePort: Gibt an, dass dies ein Service vom Typ NodePort ist.
    • app: echoheaders: Gibt an, dass jeder Pod mit diesem Label ein Mitglied des Dienstes ist.
    • cloud.google.com/app-protocols: Gibt an, dass my-port das HTTP/2-Protokoll verwenden soll.
    • port: 443, protocol: TCP und targetPort: 8433: Geben Sie an, dass der an den Dienst an TCP-Port 443 gerichtete Traffic an den TCP-Port 8422 auf einem der Mitglieds-Pods weitergeleitet werden soll.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-service.yaml

  3. Lassen Sie den Service anzeigen:

    kubectl get service echoheaders --output yaml

    Die Ausgabe sieht in 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
...

Ingress erstellen

  1. Kopieren Sie dann das folgende Manifest in eine Datei mit dem Namen my-ingress.yaml.

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echomap
spec:
  defaultBackend:
    service:
      name: echoheaders
      port:
        number: 443

    Dieses Manifest beschreibt ein Ingress, das angibt, dass eingehende Anfragen an einen Pod gesendet werden, der Mitglied des Dienstes echoheaders ist. Anfragen werden an den Pod an den targetPort weitergeleitet, der im echoheaders-Dienstmanifest angegeben ist. In dieser Übung lautet der Pod targetPort 8443.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-ingress.yaml

    Die Ausführung dieses Befehls kann einige Minuten dauern, während der Kubernetes Ingress-Controller den Application Load Balancer konfiguriert.

  3. Sehen Sie sich das Ingress-Objekt an:

    kubectl get ingress echomap --output yaml

    Die Ausgabe sieht in etwa so aus:

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

    In dieser Ausgabe lautet die IP-Adresse des Ingress 203.0.113.2.

Load-Balancer testen

gcloud

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

    gcloud compute backend-services list

  2. Ihren Backend-Dienst beschreiben:

    gcloud beta compute backend-services describe BACKEND_SERVICE_NAME --global

    Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen Ihres Backend-Dienstes.

    Die Ausgabe gibt an, dass protocol HTTP2 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.

    Load-Balancing aufrufen

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

  3. Klicken Sie auf den Namen Ihres Load-Balancers, um den Backend-Dienst aufzurufen.

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

Dienst aufrufen

Warten Sie einige Minuten, bis GKE den Load Balancer und den Backend-Dienst konfiguriert hat, und geben Sie dann die externe IP-Adresse des Load Balancers in die Adressleiste Ihres Browsers ein.

Die Ausgabe sieht in etwa so aus:

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
...

Die folgenden Ausgabeinformationen zur Anfrage vom Load Balancer an den Pod:

  • request_version=2: Gibt an, dass für die Anfrage zwischen dem Load Balancer und dem Pod HTTP/2 verwendet wurde.
  • x-forwarded-proto=http: Gibt an, dass für die Anfrage zwischen dem Browser und dem Load Balancer HTTP 1.1 und nicht HTTP/2 verwendet wurde.

Nächste Schritte