Ingress für interne Application Load Balancer

Autopilot Standard

Auf dieser Seite wird erläutert, wie Ingress für interne Application Load Balancer in Google Kubernetes Engine (GKE) funktioniert. Sie erfahren außerdem, wie Sie Ingress für interne Application Load Balancer einrichten und verwenden.

In GKE ist der interne Application 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 Application Load Balancer 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 interne Application Load Balancer

Die Verwendung von GKE Ingress für interne Application Load Balancer 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 interne Application Load Balancer unterstützt eine Vielzahl zusätzlicher Features.

Selbstverwaltete SSL-Zertifikate mit Google Cloud. Für dieses Feature werden nur regionale Zertifikate unterstützt.
Selbstverwaltete SSL-Zertifikate mit Kubernetes-Secrets.
Die BackendService-Features für Sitzungsaffinität und Zeitlimit für Verbindungsausgleich. Sie können diese Features mithilfe von BackendConfig konfigurieren.

Erforderliche Netzwerkumgebung für interne Application Load Balancer

Der interne Application 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 Backend-NEG aus, wohin die HTTP(S)-Anforderung gehen soll.

Der interne Application 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 Traffic-Fluss für einen internen Application Load Balancer, wie im vorherigen Abschnitt beschrieben.

So funktioniert der interne Application Load Balancer:

Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.
Ein Proxy empfängt und beendet die Netzwerkverbindung des Clients.
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.

HTTPS (TLS) zwischen Load-Balancer und Ihrer Anwendung

Ein interner Application 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 Application 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