GKE Ingress für Application Load Balancer

Auf dieser Seite finden Sie eine allgemeine Übersicht über Google Kubernetes Engine (GKE) Ingress für Application Load Balancer und eine Erläuterung, wie der Ingress-Controller Application Load Balancer bereitstellt, um Anwendungen für HTTP(S)-Traffic von innerhalb oder außerhalb Ihres VPC-Netzwerk verfügbar zu machen.

Diese Seite dient als primärer Einstiegspunkt, um die Funktionsweise von GKE Ingress zu verstehen. Eine detailliertere Beschreibung der zugrunde liegenden Netzwerk architektur, der Traffic-Routing-Muster und der Sicherheitsimplementierungen finden Sie unter Routing und Sicherheit von GKE Ingress.

Auf dieser Seite wird davon ausgegangen, dass Sie mit den folgenden Themen vertraut sind:

Diese Seite richtet sich an Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen sowie Netzwerkgeräte installieren, konfigurieren und unterstützen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

GKE bietet mit GKE Ingress einen integrierten und verwalteten Ingress Controller. Wenn Sie eine Ingress-Ressource in GKE erstellen, konfiguriert der Controller automatisch einen HTTPS-Load-Balancer, über den HTTP- oder HTTPS-Traffic Ihre Dienste erreichen kann. Der Ingress-Controller konfiguriert den Load-Balancer und leitet Traffic basierend auf den Regeln, die in Ihrem Ingress-Manifest und den zugehörigen Service-Objekten angegeben sind, an Anwendungen weiter, die in Ihrem Cluster ausgeführt werden.

Ein Ingress-Objekt ist einem oder mehreren Service-Objekten zugeordnet. Diesen wiederum ist jeweils ein Satz von Pods zugeordnet. Weitere Informationen dazu, wie Ingress Anwendungen mithilfe von Services bereitstellt, finden Sie unter Übersicht über das Servicenetzwerk.

Damit Sie Ingress verwenden können, müssen Sie das Add-on für HTTP-Load-Balancing aktivieren. Für GKE-Cluster ist dieses Add-on standardmäßig aktiviert. Sie sollten es nicht deaktivieren.

Unterschied zwischen Kubernetes-Dienst und Google Cloud Backend-Dienst

Das Kubernetes-Service-Objekt und das Google Cloud Backend Service-Objekt dienen ähnlichen, aber unterschiedlichen Zwecken. Obwohl sie eng miteinander verbunden sind, ist die Beziehung nicht immer 1:1.

Der GKE-Ingress-Controller fungiert als Übersetzer zwischen diesen beiden Konzepten. Wenn Sie eine Ingress-Ressource erstellen, stellt der Controller einen Google Cloud Load-Balancer bereit. Anschließend erstellt der Controller für jede eindeutige (service.name, service.port)-Kombination, auf die im Ingress-Manifest verwiesen wird, einen dedizierten Google Cloud Backend-Dienst.

Ein Ingress-Manifest kann beispielsweise denselben Kubernetes-Dienstnamen haben, aber für zwei separate host- oder path-Regeln auf einen anderen service.port verweisen. In diesem Fall erstellt der GKE-Ingress-Controller zwei separate Backend-Dienste. Daher kann ein Kubernetes-Service-Objekt mehreren Google Cloud Backend-Diensten zugeordnet sein.

Ingress für externen und internen Traffic

Es gibt zwei Arten von GKE-Ingress-Ressourcen:

Erforderliche Netzwerkumgebung für externe Application Load Balancer

Der externe Application Load Balancer ist ein verwaltetes, global verteiltes System, das Google Front End-Proxys (GFE) verwendet, die im Edge-Netzwerk von Google bereitgestellt werden. Diese Proxys befinden sich nicht in Ihrem VPC-Netzwerk. Wenn ein Client eine Anfrage an die externe IP-Adresse des Load-Balancers sendet, wird die Anfrage über das Anycast-Netzwerk von Google an das nächstgelegene GFE weitergeleitet. Das GFE beendet den Nutzertraffic (einschließlich TLS, falls konfiguriert) und leitet den Traffic dann an die Backend-Pods in Ihrem GKE-Cluster weiter.

Damit dieser Ablauf funktioniert, erstellt der GKE-Ingress-Controller automatisch Firewallregeln, um Traffic von den GFEs und von Google Cloud's Systemdiagnosesystemen an Ihre Pods zuzulassen. Diese Regeln lassen Traffic aus den bekannten IP-Adressbereichen von Google (130.211.0.0/22 und 35.191.0.0/16) zu.

So funktioniert der externe Application Load Balancer:

  1. Ein Client sendet eine Anfrage an die IP-Adresse und den Port der Weiterleitungsregel des Load-Balancers.
  2. Die Anfrage wird an einen Google Front End-Proxy (GFE) im globalen Netzwerk von Google weitergeleitet. Dieser Proxy beendet die Netzwerkverbindung des Clients.
  3. Der GFE-Proxy leitet die Anfrage an den entsprechenden Backend-Pod-Endpunkt in Ihrem GKE-Cluster weiter. Dies richtet sich nach der URL-Zuordnung und den Backend-Diensten des Load-Balancers.

Im Gegensatz zum internen Application Load Balancer ist es nicht erforderlich, ein Nur-Proxy-Subnetz in Ihrem VPC-Netzwerk für einen externen Application Load Balancer zu 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 Back-End-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 erstellten Proxy interne IP Adressen zuzuweisen Google Cloud.

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.

Bild

So funktioniert der interne Application 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 Backend-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.

Verhalten des GKE-Ingress-Controllers

Ob der GKE-Ingress-Controller ein Ingress verarbeitet, hängt vom Wert der Annotation kubernetes.io/ingress.class ab:

Wert von kubernetes.io/ingress.class ingressClassName Wert Verhalten des GKE-Ingress-Controllers
Nicht festgelegt Nicht festgelegt Verarbeiten Sie das Ingress-Manifest und erstellen Sie einen externen Application Load Balancer.
Nicht festgelegt Beliebiger Wert Keine Aktion. Das Ingress-Manifest könnte von einem Ingress-Controller eines Drittanbieters verarbeitet werden, falls ein solcher bereitgestellt wurde.
gce Beliebiger Wert. Dieses Feld wird ignoriert. Verarbeiten Sie das Ingress-Manifest und erstellen Sie einen externen Application Load Balancer.
gce-internal Beliebiger Wert. Dieses Feld wird ignoriert. Verarbeiten Sie das Ingress-Manifest und erstellen Sie einen internen Application Load Balancer.
Einen anderen Wert als gce oder gce-internal festlegen Beliebiger Wert Keine Aktion. Das Ingress-Manifest könnte von einem Ingress-Controller eines Drittanbieters verarbeitet werden, falls ein solcher bereitgestellt wurde.

Einstellung der Annotation kubernetes.io/ingress.class

Obwohl die kubernetes.io/ingress.class Annotation in Kubernetes verworfen wurde, verwendet GKE diese Annotation weiterhin. Sie müssen diese Annotation verwenden, um die Ingress-Klasse zu identifizieren.

Wenn Sie Ihre Konfiguration anwenden, wird möglicherweise eine Warnung zur Einstellung angezeigt. In dieser Warnung wird darauf hingewiesen, dass die Annotation verworfen wurde, und Sie werden aufgefordert, stattdessen das Feld ingressClassName zu verwenden. Sie können die Warnung ignorieren, da GKE Ingress weiterhin ausschließlich auf die Annotation kubernetes.io/ingress.class angewiesen ist.

Ressourcenzuordnungen zwischen Ingress und Compute Engine

Der GKE-Ingress-Controller stellt Ressourcen des Compute Engine-Load-Balancers bereit und verwaltet diese basierend auf den Ingress-Ressourcen, die im Cluster bereitgestellt werden. Die Zuordnung von Compute Engine-Ressourcen hängt von der Struktur der Ingress-Ressource ab.

Das folgende Manifest beschreibt ein Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Dieses Ingress-Manifest weist GKE an, die folgenden Compute Engine-Ressourcen zu erstellen:

  • Eine Weiterleitungsregel und eine IP-Adresse.
  • Compute Engine-Firewallregeln, die Traffic für Load-Balancer-Systemdiagnosen und Anwendungstraffic von Google Front Ends oder von Envoy-Proxys zulassen.
  • Ein Ziel-HTTP-Proxy und ein Ziel-HTTPS-Proxy, falls Sie TLS konfiguriert haben.
  • Eine URL-Zuordnung mit einer einzelnen Hostregel, die auf ein einzelnes Tool zum Abgleich von Pfaden verweist. Das Tool zum Abgleich von Pfaden hat zwei Pfadregeln, eine für /* und eine für /discounted. Jede Pfadregel wird einem eindeutigen Backend-Dienst zugeordnet.
  • NEGs, die eine Liste der Pod-IP-Adressen von jedem Dienst als Endpunkte enthalten. Diese werden als Ergebnis der Dienste my-discounted-products und my-products erstellt.

Load-Balancing-Methoden

GKE unterstützt containernatives Load-Balancing und Instanzgruppen.

Containernatives Load-Balancing

Containernatives Load-Balancing bezeichnet den Load-Balancing-Vorgang direkt an Pod-Endpunkten in GKE. Containernatives Load-Balancing verwendet Netzwerk-Endpunktgruppen (NEGs) vom Typ GCE_VM_IP_PORT, wobei die Endpunkte die IP-Adressen der Pods sind.

Das containernative Load-Balancing wird immer für das interne GKE-Ingress verwendet und ist für das externe Ingress optional. Der Ingress-Controller erstellt den Load-Balancer, einschließlich der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen und Firewallregeln.

Containernatives Load-Balancing unterstützt Pod-basierte Sitzungsaffinität.

GKE aktiviert das containernative Load-Balancing automatisch, wenn alle folgenden Bedingungen erfüllt sind:

  • Der Cluster ist VPC-nativ.
  • Der Cluster verwendet kein freigegebene VPC-Netzwerk.
  • Der Cluster verwendet keine GKE-Netzwerkrichtlinie.
  • Für den Cluster ist das Add-on HttpLoadBalancing aktiviert. Für GKE-Cluster ist das Add-on HttpLoadBalancing standardmäßig aktiviert. Sie sollten es nicht deaktivieren.

Wenn GKE das containernative Load-Balancing aktiviert, werden Dienste automatisch mit cloud.google.com/neg: '{"ingress": true}' annotiert. Diese Annotation löst die Erstellung einer NEG aus, die die Pod-IPs widerspiegelt, sodass Compute Engine-Load-Balancer direkt mit Pods kommunizieren können.

Für Cluster, bei denen NEGs nicht die Standardeinstellung ist, wird trotzdem dringend empfohlen , containernatives Load-Balancing zu verwenden, das explizit pro Service aktiviert werden muss.

Sie können auch eigenständige NEGs erstellen, um die Flexibilität zu erhöhen. In diesem Fall sind Sie für das Erstellen und Verwalten aller Aspekte des Load-Balancers verantwortlich.

Vorteile

Durch die Verwendung von NEGs bietet das containernative Load-Balancing eine leistungsstärkere und stabilere Netzwerkleistung:

Verbesserte Netzwerkleistung: Ohne containernatives Load-Balancing wird der Traffic an die Knoteninstanzgruppen weitergeleitet und dann über iptables Regeln konfiguriert von kube-proxy an den Ziel-Pod weitergeleitet. Mit dem containernativen Load-Balancing wird der Traffic direkt an die Pods weitergeleitet, sodass er nicht über die VM-IP und das kube-proxy-Netzwerk auf dem Knoten weitergeleitet werden muss. Dieser Ablauf vermeidet zusätzliche Netzwerk-Hops und verbessert die Latenz und den Durchsatz.

Verbesserte Systemdiagnosen: Pod-Readiness Gates werden implementiert, um den Status von Pods aus Sicht des Load-Balancers zu ermitteln, anstatt sich ausschließlich auf In-Cluster-Systemdiagnosen zu verlassen. Diese wichtige Funktion informiert den Load-Balancer über Lebenszyklusereignisse von Pods (Start, Verlust usw.) und verbessert die Trafficstabilität. Weitere Informationen zur Verwendung von Pod-Readiness-Gates zur Ermittlung des Pod-Status finden Sie unter Pod-Bereitschaft.

Bessere Sichtbarkeit: Mit dem containernativen Load-Balancing haben Sie Einblick in die Latenz vom Application Load Balancer direkt zu jedem Pod. Da die Latenz nicht mehr auf Knoten-IP-Ebene aggregiert wird, wird die Fehlerbehebung für Ihre Dienste auf NEG-Ebene einfacher.

Unterstützung für Cloud Service Mesh: Das NEG-Datenmodell ist erforderlich, um Cloud Service Mesh zu verwenden, Google Clouddie vollständig verwaltete Traffic-Steuerungsebene von für Service Mesh.

Einschränkungen von containernativen Load-Balancern

Für containernative Load-Balancer über eingehenden Traffic in GKE gelten folgende Einschränkungen:

  • Containernative Load-Balancer unterstützen keine externen Passthrough-Netzwerk-Load-Balancer.
  • Sie dürfen die Konfiguration des von GKE erstellten Application Load Balancers nicht manuell ändern oder aktualisieren. Alle vorgenommenen Änderungen werden von GKE überschrieben.

Preise für containernative Load-Balancer

Es wird Ihnen der Application Load Balancer in Rechnung gestellt, der von der Ingress-Ressource bereitgestellt wird, die Sie in dieser Anleitung erstellen. Informationen zu Load-Balancer-Preisen finden Sie auf der Seite mit den Preisen für Cloud Load Balancing unter Load-Balancing und Weiterleitungsregeln.

Instanzgruppen

Bei Verwendung von Instanzgruppen senden Compute Engine-Load-Balancer Traffic an VM-IP-Adressen als Back-Ends. Wenn Sie Container auf VMs ausführen, bei denen sich mehrere Container dieselbe Hostschnittstelle teilen, gelten die folgenden Einschränkungen:

  • Es erzeugt zwei Load-Balancing-Hops – einen Hop vom Load-Balancer zum NodePort der VM und einen weiteren Hop durch kube-proxy-Routing an die Pod-IP-Adressen, die sich auf einer anderen VM befinden können.
  • Zusätzliche Hops führen zu einer erhöhten Latenz und einem komplexeren Traffic-Pfad.
  • Der Load-Balancer von Compute Engine ist für Pods nicht direkt sichtbar, sodass das Balancing von Traffic nicht optimal erfolgt.
  • Umgebungsereignisse wie VM- oder Pod-Verluste führen aufgrund des doppelten Traffic-Hops eher zu unerwünschten Trafficverlusten.

Externe Ingress- und routenbasierte Cluster

Wenn Sie routenbasierte Cluster mit externem Ingress verwenden, kann der GKE-Ingress-Controller kein containernatives Load-Balancing mit GCE_VM_IP_PORT-Netzwerk-Endpunktgruppen (NEGs) verwenden. Stattdessen verwendet der Ingress-Controller nicht verwaltete Instanzgruppen-Back-Ends, die alle Knoten in allen Knotenpools enthalten. Wenn diese nicht verwalteten Instanzgruppen auch von LoadBalancer-Diensten verwendet werden, kann dies zu Problemen im Zusammenhang mit der Beschränkung für Instanzgruppen mit einzelnem Load-Balancing führen.

Einige ältere externe Ingress-Objekte, die in VPC-nativen Clustern erstellt wurden, verwenden möglicherweise Instanzgruppen-Backends in den Backend-Diensten jedes von ihnen erstellten externen Application Load Balancers. Dies ist für den internen Ingress nicht relevant, da interne Ingress-Ressourcen immer GCE_VM_IP_PORT-NEGs verwenden und VPC-native Cluster erfordern.

Informationen zum Beheben von 502-Fehlern mit externem Ingress finden Sie unter Externer Ingress erzeugt HTTP-502-Fehler.

Einschränkungen des GKE-Ingress-Controllers

  • GKE Ingress unterstützt keine Zertifikate, die vom Zertifikatmanager verwaltet werden. Wenn Sie vom Zertifikatmanager verwaltete Zertifikate verwenden möchten, verwenden Sie die Gateway API.

  • Bei Clustern mit NEGs kann der Zeitraum für den Abgleich von eingehendem Traffic von der Anzahl der Ingress-Ressourcen abhängen. Beispiel: Ein Cluster mit 20 Ingress-Ressourcen mit jeweils 20 verschiedenen NEG-Back-Ends kann zu einer Latenz von über 30 Minuten für den Abgleich einer Ingress-Änderung führen. Dies betrifft insbesondere regionale Cluster aufgrund der erhöhten Anzahl an benötigten NEGs.

  • Es gelten die Kontingente für URL-Zuordnungen.

  • Es gelten die Kontingente für Compute Engine-Ressourcen.

  • Wenn Sie keine NEGs mit dem GKE-Ingress Controller verwenden,sind GKE Cluster auf 1.000 Knoten begrenzt. Wenn Dienste mit NEGs bereitgestellt werden, gibt es kein Knotenlimit in GKE. Alle über Ingress bereitgestellten NEG-unabhängigen Dienste funktionieren in Clustern mit mehr als 1.000 Knoten nicht ordnungsgemäß.

  • Damit der GKE-Ingress-Controller Ihre readinessProbes als Systemdiagnose verwenden kann, müssen zum Zeitpunkt der Ingress-Erstellung die Pods für ein Ingress vorhanden sein. Wenn Ihre Replikate auf 0 skaliert werden, wird die standardmäßige Systemdiagnose angewendet. Weitere Informationen finden Sie in diesem GitHub-Problemkommentar zu Systemdiagnosen.

  • Änderungen an der readinessProbe eines Pods wirken sich nicht auf den Ingress aus, nachdem er erstellt wurde.

  • Ein externer Application Load Balancer beendet TLS an global verteilten Orten, um die Latenz zwischen Clients und dem Load Balancer zu minimieren. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, sollten Sie stattdessen einen benutzerdefinierten Ingress-Controller verwenden, der über einen GKE-Service vom Typ LoadBalancer bereitgestellt wird. Außerdem sollten Sie TLS auf Back-Ends beenden, die sich in Regionen befinden, die für Ihren Bedarf geeignet sind.

  • Das Kombinieren mehrerer Ingress-Ressourcen zu einem einzigen Google Cloud Load-Balancer wird nicht unterstützt.

  • Sie müssen die gegenseitige TLS-Authentifizierung für Ihre Anwendung deaktivieren, da sie für externe Application Load Balancer nicht unterstützt wird.

  • Ingress kann für sein Frontend nur die HTTP-Ports 80 und 443 verfügbar machen.

Nächste Schritte