GKE Ingress für Application Load Balancer

Auf dieser Seite erhalten Sie einen allgemeinen Überblick über GKE-Ingress für Application Load Balancer. Außerdem wird erläutert, wie der Ingress-Controller Application Load Balancer bereitstellt, um Anwendungen für HTTP(S)-Traffic aus Ihrem VPC-Netzwerk oder von außerhalb verfügbar zu machen.

Diese Seite dient als primärer Einstiegspunkt, um die Funktionsweise von GKE Ingress zu verstehen. Weitere Informationen zur zugrunde liegenden Netzwerkarchitektur, zu Traffic-Routing-Mustern und zu Sicherheitsimplementierungen finden Sie unter GKE-Ingress-Routing und ‑Sicherheit.

Auf dieser Seite wird davon ausgegangen, dass Sie mit Folgendem 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 inGoogle Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

GKE bietet einen integrierten und verwalteten Ingress-Controller namens GKE Ingress. 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 den Traffic basierend auf den Regeln, die in Ihrem Ingress-Manifest und den zugehörigen Serviceobjekten 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 Überblick ü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 dürfen es nicht deaktivieren.

Unterschied zwischen Kubernetes-Dienst und Google Cloud -Back-End-Dienst

Das Kubernetes-Dienstobjekt und das Google Cloud backend service-Objekt haben ähnliche, aber unterschiedliche Zwecke. Sie hängen zwar eng zusammen, aber nicht immer im Verhältnis 1:1.

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

Ein Ingress-Manifest kann beispielsweise denselben Kubernetes-Dienstnamen haben, aber für zwei separate host- oder path-Regeln auf ein anderes service.port verweisen. In diesem Fall erstellt der GKE Ingress-Controller zwei separate Backend-Dienste. Daher kann ein Kubernetes-Dienstobjekt mit mehreren Google Cloud Back-End-Diensten verknüpft 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 GFE-Proxys (Google Front End) 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 Nutzer-Traffic (einschließlich TLS, falls konfiguriert) und leitet ihn 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 den Systemdiagnosesystemen vonGoogle Cloudzu Ihren Pods zuzulassen. Mit diesen Regeln wird Traffic von den bekannten IP-Adressbereichen von Google (130.211.0.0/22 und 35.191.0.0/16) zugelassen.

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 Back-End-Pod-Endpunkt in Ihrem GKE-Cluster weiter. Dies richtet sich nach der URL-Zuordnung und den Back-End-Diensten des Load-Balancers.

Im Gegensatz zum internen Application Load Balancer ist für einen externen Application Load Balancer keine Konfiguration eines Nur-Proxy-Subnetzes in Ihrem VPC-Netzwerk erforderlich.

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

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

Verhalten des GKE-Ingress-Controllers

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

kubernetes.io/ingress.class Wert 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 Annotation kubernetes.io/ingress.class 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. Diese Warnung weist darauf hin, dass die Anmerkung veraltet ist, und fordert Sie auf, 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, die mit einer einzelnen Hostregel 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 Dienstes my-discounted-products und my-products erstellt.

Load-Balancing-Methoden

GKE unterstützt natives Load-Balancing für Container und Instanzgruppen.

Containernatives Load-Balancing

Containernatives Load-Balancing bezeichnet das Load-Balancing direkt an Pod-Endpunkten in GKE. Für das containernative Load-Balancing werden Netzwerk-Endpunktgruppen (NEGs) vom Typ GCE_VM_IP_PORT verwendet, 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. So können Compute Engine-Load-Balancer direkt mit Pods kommunizieren.

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 leistungsfähigere und stabilere Netzwerkverbindung:

Verbesserte Netzwerkleistung: Ohne containernatives Load-Balancing wird der Traffic an die Knoteninstanzgruppen weitergeleitet und dann über iptables-Regeln, die von kube-proxy konfiguriert werden, an den Ziel-Pod weitergeleitet. Beim containernativen Load-Balancing wird der Traffic direkt auf die Pods verteilt. Das Routing über die VM-IP-Adresse und das kube-proxy-Netzwerk auf dem Knoten ist nicht erforderlich. Bei diesem Ablauf werden zusätzliche Netzwerk-Hops vermieden und Latenz und Durchsatz verbessert.

Erweiterte Systemdiagnosen: Pod-Readiness-Gates werden implementiert, um den Pod-Status aus Sicht des Load-Balancers zu ermitteln, anstatt sich nur auf In-Cluster-Systemdiagnosen zu verlassen. Diese wichtige Funktion informiert den Load-Balancer über Pod-Lebenszyklusereignisse (Start, Verlust usw.) und verbessert die Trafficstabilität. Weitere Informationen dazu, wie Pod-Readiness-Gates verwendet werden, um den Pod-Zustand zu ermitteln, finden Sie unter Pod-Bereitschaft.

Bessere Sichtbarkeit: Mit dem containernativen Load-Balancing haben Sie Einblick in die Latenz des Application Load Balancers zu jedem Pod. Da die Latenz nicht mehr auf Knotenebene aggregiert wird, ist 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, die vollständig verwaltete Traffic-Steuerungsebene von Google Cloudfür Service Mesh, zu verwenden.

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-Network-Load-Balancer.
  • Sie dürfen die Konfiguration des von GKE erstellten Anwendungs-Load-Balancers nicht manuell ändern oder aktualisieren. Alle vorgenommenen Änderungen werden von GKE überschrieben.

Preise für containernative Load-Balancer

Es wird Ihnen der Anwendungs-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 „VPC-Preise“ unter Load-Balancing und Weiterleitungsregeln.

Instanzgruppen

Bei Verwendung von Instanzgruppen senden Compute Engine-Load-Balancer Traffic an VM-IP-Adressen als Back-Ends. Beim Ausführen von Containern auf VMs, auf denen Container dieselbe Hostschnittstelle nutzen, führt dies zu den folgenden Einschränkungen:

  • Es erzeugt zwei Load-Balancing-Hops – einen Hop vom Load-Balancer zum VM-NodePort 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 von Certificate Manager verwaltete Zertifikate verwenden möchten, nutzen 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.

  • Über Ingress können nur die HTTP-Ports 80 und 443 für das Frontend verfügbar gemacht werden.

Nächste Schritte