Ingress für internes HTTP(S)-Load-Balancing

Auf dieser Seite wird erläutert, wie Ingress für internes HTTP(S)-Load-Balancing in Google Kubernetes Engine (GKE) funktioniert. Sie erfahren außerdem, wie Sie Ingress für internes HTTP(S)-Load-Balancing einrichten und verwenden.

In GKE ist der interne HTTP(S)-Load-Balancer ein Proxy-basierter, regionaler Layer-7-Load-Balancer, mit dem Sie Ihre Services hinter einer internen Load-Balancing-IP-Adresse ausführen und skalieren können. GKE Ingress-Objekte unterstützen das interne HTTP(S)-Load-Balancing nativ durch die Erstellung von Ingress-Objekten in GKE-Clustern.

Allgemeine Informationen zur Verwendung von Ingress für Load-Balancing in GKE finden Sie unter HTTP(S)-Load-Balancing mit Ingress.

Vorteile der Verwendung von Ingress für den internen HTTP(S)-Load-Balancer

Die Verwendung von GKE Ingress für das interne HTTP(S)-Load-Balancing bietet folgende Vorteile:

  • Ein hochverfügbarer, von GKE verwalteter Ingress-Controller.
  • Load-Balancing für interne Dienst-zu-Dienst-Kommunikation.
  • Containernatives Load-Balancing mit Netzwerk-Endpunktgruppen (NEG).
  • Anwendungsrouting mit HTTP- und HTTPS-Unterstützung.
  • Zuverlässige Compute Engine-Systemdiagnosen für stabile Dienste.
  • Auf Envoy beruhende Proxys, die bedarfsabhängig bereitgestellt werden, um die erforderliche Traffic-Kapazität zu gewährleisten.

Unterstützung für Google Cloud-Features

Ingress für internes HTTP(S)-Load-Balancing unterstützt eine Vielzahl von zusätzlichen Features.

Erforderliche Netzwerkumgebung

Der interne HTTP(S)-Load-Balancer stellt einen Pool von Proxys für Ihr Netzwerk bereit. Die Proxys werten anhand von Faktoren wie der URL-Zuordnung, der Sitzungsaffinität des BackendService und des Balancing-Modus jeder Back-End-NEG aus, wohin die HTTP(S)-Anforderung gehen soll.

Der interne HTTP(S)-Load-Balancer einer Region verwendet das Nur-Proxy-Subnetz für diese Region in Ihrem VPC-Netzwerk, um jedem von Google Cloud erstellten Proxy interne IP-Adressen zuzuweisen.

Standardmäßig stammt die IP-Adresse, die der Weiterleitungsregel eines Load-Balancers zugewiesen ist, aus dem Subnetzbereich des Knotens, der von GKE zugewiesen wird, und nicht von dem Nur-Proxy-Subnetz. Sie können auch manuell eine IP-Adresse für die Weiterleitungsregel angeben, und zwar aus jedem beliebigen Subnetz, wenn Sie die Regel erstellen.

Das folgende Diagramm bietet eine Übersicht über den Datentraffic für den internen HTTP(S)-Load-Balancer.

Diagramm zu Ingress für internes HTTP(S)-Load-Balancing

So funktioniert der interne HTTP(S)-Load-Balancer:

  1. Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.
  2. Ein Proxy empfängt und beendet die Netzwerkverbindung des Clients.
  3. Der Proxy stellt eine Verbindung zum entsprechenden Endpunkt (Pod) in einer NEG her, wie anhand der URL-Zuordnung und der Back-End-Dienste des Load-Balancers bestimmt.

Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Die Quell-IP-Adresse jedes Pakets, das von einem Proxy an einen Endpunkt gesendet wird, ist die interne IP-Adresse, die diesem Proxy aus dem Nur-Proxy-Subnetz zugewiesen ist.

Der GKE Ingress-Controller verwaltet das Deployment von Firewallregeln, sodass Sie sie nicht manuell bereitstellen müssen.

HTTPS (TLS) zwischen Load-Balancer und Ihrer Anwendung

Ein interner HTTP(S)-Load-Balancer fungiert als Proxy zwischen Ihren Clients und Ihrer Anwendung. Clients können HTTP oder HTTPS verwenden, um mit dem Load-Balancer-Proxy zu kommunizieren. Die Verbindung vom Load-Balancer-Proxy zu Ihrer Anwendung verwendet standardmäßig HTTP. Wenn Ihre Anwendung jedoch in einem GKE-Pod ausgeführt wird und HTTPS-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass er bei der Weiterleitung von Anfragen an Ihre Anwendung HTTPS verwendet.

Verwenden Sie zum Konfigurieren des Protokolls, das zwischen dem Load-Balancer und Ihrer Anwendung verwendet wird, die Anmerkung cloud.google.com/app-protocols in Ihrem Dienstmanifest.

Das folgende Dienstmanifest legt zwei Ports fest. Die Annotation gibt an, dass ein interner HTTP(S)-Load-Balancer HTTP verwenden soll, wenn er auf Port 80 des Dienstes gerichtet ist, und HTTPS, wenn er auf Port 443 des Dienstes gerichtet ist.

Sie müssen in der Annotation das Feld name des Ports verwenden. Verwenden Sie kein anderes Feld wie targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

Nächste Schritte