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

Auf dieser Seite erhalten Sie eine allgemeine Übersicht über die Funktionsweise von Ingress für HTTP(S)-Load-Balancing. Google Kubernetes Engine (GKE) bietet mit GKE Ingress einen integrierten und verwalteten Ingress-Controller. Mit diesem Controller werden Ingress-Ressourcen als Google Cloud-Load-Balancer für HTTP(S)-Arbeitslasten in GKE implementiert.

Übersicht

In GKE definiert ein Ingress-Objekt Regeln zum Weiterleiten von HTTP(S)-Traffic an Anwendungen, die in einem Cluster ausgeführt werden. Ein Ingress-Objekt ist einem oder mehreren Service-Objekten zugeordnet. Diesen wiederum ist jeweils ein Satz von Pods zugeordnet.

Wenn Sie ein Ingress-Objekt erstellen, erstellt der GKE-Ingress-Controller einen Google Cloud-HTTP(S)-Load-Balancer und konfiguriert diesen gemäß den Informationen im Ingress und in den zugehörigen Services.

Damit Sie Ingress verwenden können, muss das Add-on für HTTP-Load-Balancing aktiviert sein. Für GKE-Cluster ist HTTP-Load-Balancing standardmäßig aktiviert und darf nicht deaktiviert werden.

Ingress für externen und internen Traffic

Es gibt zwei Arten von GKE-Ingress-Ressourcen:

Features des HTTP(S)-Load-Balancing

Das durch Ingress konfigurierte HTTP(S)-Load-Balancing umfasst die folgenden Features:

  • Flexible Konfiguration für Services. Ein Ingress definiert, wie Traffic Ihre Services erreicht und an Ihre Anwendung weitergeleitet wird. Darüber hinaus stellt ein Ingress eine einzelne IP-Adresse für mehrere Services in Ihrem Cluster bereit.
  • Integration in Google Cloud-Netzwerkdienste
  • Unterstützung mehrerer TLS-Zertifikate. Ein Ingress kann die Verwendung mehrerer TLS-Zertifikate für die Beendigung der Anfrage festlegen.

Eine umfassende Liste finden Sie unter Ingress-Features.

Containernatives Load-Balancing

Containernatives Load-Balancing bezeichnet das Load-Balancing direkt an Pod-Endpunkten in GKE mit Netzwerk-Endpunktgruppen (NEGs).

Bei Verwendung von Instanzgruppen senden Compute Engine-Load-Balancer Traffic an VM-IP-Adressen als Back-Ends. Beim Ausführen von Containern auf VMs, in denen Container dieselbe Hostschnittstelle nutzen, führt dies zu einigen 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-Adresse, die sich auf einer anderen VM befinden kann.
  • 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.

Bei NEGs erfolgt das Load-Balancing des Traffics direkt vom Load-Balancer auf die Pod-IP und er durchläuft nicht die VM-IP- und das kube-proxy-Netzwerk. Darüber hinaus werden Pod-Readiness-Gates implementiert, um den Status von Pods aus Sicht des Load-Balancers und nicht nur der Kubernetes-In-Cluster-Systemdiagnosen zu ermitteln. Dadurch wird die allgemeine Trafficstabilität verbessert, da die Load-Balancer-Infrastruktur über Lebenszyklusereignisse wie Pod-Start, Pod-Verlust oder VM-Verlust informiert wird. Diese Funktionen lösen die oben genannten Einschränkungen auf und führen zu einem leistungsstärkeren und stabileren Netzwerk.

Containernatives Load-Balancing ist für Services standardmäßig aktiviert, wenn alle folgenden Bedingungen erfüllt sind:

  • Für Services, die in GKE-Clustern 1.17.6-gke.7 und höher erstellt wurden
  • VPC-native Cluster verwenden
  • Keine freigegebene VPC verwenden
  • GKE-Netzwerkrichtlinie wird nicht verwendet

In diesen Bedingungen werden Dienste automatisch mit cloud.google.com/neg: '{"ingress": true}' annotiert, um anzugeben, dass eine NEG erstellt werden sollte, um die Pod-IP-Adressen innerhalb des Dienstes zu spiegeln. Über die NEG können Compute Engine-Load-Balancer direkt mit Pods kommunizieren. Beachten Sie, dass vorhandene Dienste, die vor GKE 1.17.6-gke.7+ erstellt wurden, automatisch vom Dienstüberwacher annotiert werden.

Bei GKE 1.17.6-gke.7+ Clustern mit automatischer NEG-Annotation können NEGs deaktiviert werden und der Compute Engine-Load-Balancer kann gezwungen werden, eine Instanzgruppe als Back-Ends zu verwenden. Dazu annotieren Sie Services explizit mit cloud.google.com/neg: '{"ingress": false}'.

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. Die Annotation sollte so auf Services angewendet werden:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

Mehrere Back-End-Dienste

Jeder externe HTTP(S)-Load-Balancer oder interne HTTP(S)-Load-Balancer verwendet eine einzelne URL-Zuordnung, die auf einen oder mehrere Back-End-Dienste verweist. Ein Back-End-Dienst entspricht jedem Dienst, auf den der Ingress verweist.

Beispielsweise können Sie den Load-Balancer so konfigurieren, dass Anfragen je nach URL-Pfad an verschiedene Back-End-Dienste weitergeleitet werden. An "your-store.example" gesendete Anfragen können an einen Back-End-Dienst weitergeleitet werden, der Artikel mit Standardpreis anzeigt. An "your-store.example/discounted" gesendete Anfragen können an einen Back-End-Dienst weitergeleitet werden, der reduzierte Artikel anzeigt.

Sie können den Load-Balancer auch so konfigurieren, dass Anfragen gemäß dem Hostnamen weitergeleitet werden. An "your-store.example" gesendete Anfragen können an einen Back-End-Dienst gehen, an "your-experimental-store.example" gesendete Anfragen an einen anderen.

In einem GKE-Cluster können Sie einen HTTP(S)-Load-Balancer durch ein Kubernetes Ingress-Objekt erstellen und konfigurieren. Ein Ingress-Objekt ist einem oder mehreren Service-Objekten zugeordnet. Diesen wiederum ist jeweils ein Satz von Pods zugeordnet.

Dies ist ein Manifest für ein Ingress mit der Bezeichnung my-ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Wenn Sie das Ingress-Objekt erstellt haben, erstellt und konfiguriert der GKE-Ingress-Controller einen externen HTTP(S)-Load-Balancer oder einen internen HTTP(S)-Load-Balancer gemäß den Informationen im Ingress und in den zugehörigen Services. Der Load-Balancer erhält außerdem eine stabile IP-Adresse, die Sie einem Domainnamen zuordnen können.

Nehmen Sie im vorherigen Beispiel an, dass Sie die IP-Adresse des Load-Balancers dem Domainnamen "your-store.example" zugeordnet haben. Wenn ein Client eine Anfrage an "your-store.example" sendet, wird die Anfrage an einen Kubernetes-Service mit dem Namen my-products an Port 60000 weitergeleitet. Wenn ein Client hingegen eine Anfrage an "your-store.example/discounted" sendet, wird die Anfrage an einen Kubernetes-Service namens my-discounted-products an Port 80 weitergeleitet.

Das einzige unterstützte Platzhalterzeichen für das Feld path eines Ingress ist das Zeichen *. Das Zeichen * muss auf einen Schrägstrich (/) folgen und das letzte Zeichen des Musters sein. Beispiel: /*, /foo/* und /foo/bar/* sind gültige Muster, *, /foo/bar* und /foo/*/bar jedoch nicht.

Ein spezifischeres Muster hat Vorrang vor einem weniger spezifischen Muster. Wenn sowohl /foo/* als auch /foo/bar/* vorhanden sind, wird /foo/bar/bat für den Abgleich mit /foo/bar/* herangezogen.

Weitere Informationen zu Pfadeinschränkungen und zum Musterabgleich finden Sie in der Dokumentation zu URL-Zuordnungen.

Das Manifest für den my-products-Service könnte so aussehen:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

Im Service-Manifest müssen Sie type: NodePort verwenden, sofern Sie nicht containernatives Load-Balancing verwenden. Für containernatives Load-Balancing verwenden Sie type: ClusterIP.

Im Service-Manifest wird im Feld selector angegeben, dass jeder Pod, der sowohl das Label app: products als auch das Label department: sales hat, Mitglied dieses Services ist.

Wenn eine Anfrage an den Service an Port 60000 eingeht, wird sie an einen der Mitglieder-Pods an TCP-Port 50000 weitergeleitet.

Für jeden Mitglieds-Pod ist ein Container erforderlich, der den TCP-Port 50000 überwacht.

Das Manifest für den my-discounted-products-Service könnte so aussehen:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Im Service-Manifest wird im Feld selector angegeben, dass jeder Pod, der sowohl das Label app: discounted-products als auch das Label department: sales hat, Mitglied dieses Services ist.

Der über TCP-Port 80 an den Service gerichtete Traffic wird in einem der Mitglieds-Pods an TCP-Port 8080 weitergeleitet.

Dafür muss jeder Mitglieds-Pod einen Container haben, der den TCP-Port 8080 überwacht.

Standard-Back-End

Sie können ein Standard-Back-End angeben, indem Sie in Ihrem Ingress-Manifest das Feld backend ausfüllen. Jede Anfrage, die nicht mit den Pfaden im Feld rules übereinstimmt, wird an den Service und den Port gesendet, die im Feld backend angegeben sind. Zum Beispiel werden im folgenden Ingress alle Anfragen, die nicht mit / oder /discounted übereinstimmen, an einen Service namens my-products an Port 60001 gesendet.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-products
    servicePort: 60001
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Wenn Sie kein Standard-Back-End angeben, stellt GKE ein Standard-Back-End bereit, das den Fehler 404 zurückgibt.

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. Die Kenntnis dieser Ressourcenzuordnungen hilft Ihnen bei Planung, Entwurf und Fehlerbehebung.

Im Manifest my-ingress im Abschnitt Mehrere Back-End-Dienste ist eine externe Ingress-Ressource mit zwei URL-Pfadübereinstimmungen angegeben, die auf zwei verschiedene Kubernetes-Services verweisen. Hier einige der Compute Engine-Ressourcen, die im Auftrag von my-ingress erstellt wurden:

  • Eine Weiterleitungsregel und eine IP-Adresse.
  • Compute Engine-Firewallregeln, die Traffic für Load-Balancer-Systemdiagnosen und Anwendungstraffic von Google Front Ends oder 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 einen einzelnen Pfad-Matcher verweist. Der Pfad-Matcher hat zwei Pfadregeln: eine für /* und eine für /discounted. Jede Pfadregel wird einem eindeutigen Back-End-Dienst zugeordnet.
  • NEGs, die eine Liste der Pod-IPs von jedem Dienst als Endpunkte enthalten. Diese werden als Ergebnis der Services my-discounted-products und my-products erstellt. Im folgenden Diagramm sind die Zuordnungen zwischen Ingress- und Compute Engine-Ressourcen im Überblick dargestellt.

Diagramm zur Zuordnung zwischen Ingress- und Compute Engine-Ressourcen

Bereitstellungsoptionen für SSL-Zertifikate

Sie können einem HTTP(S)-Load-Balancer SSL-Zertifikate auf drei Arten bereitstellen:

Von Google verwaltete Zertifikate
Von Google verwaltete SSL-Zertifikate werden für Ihre Domains bereitgestellt, verlängert und verwaltet. Verwaltete Zertifikate unterstützen keine Domains mit Platzhaltern.
Mit Google Cloud gemeinsam genutzte, selbstverwaltete Zertifikate
Sie können Ihr eigenes SSL-Zertifikat bereitstellen und in Ihrem Google Cloud-Projekt eine Zertifikatsressource erstellen. Anschließend haben Sie die Möglichkeit, die Zertifikatsressource in einer Annotation in einem Ingress aufzulisten, um einen HTTP(S)-Load-Balancer zu erstellen, der das Zertifikat verwendet. Weitere Informationen finden Sie in der Anleitung für vorinstallierte Zertifikate.
In Secret-Ressourcen bereitgestellte selbstverwaltete Zertifikate
Sie können Ihr eigenes SSL-Zertifikat in einem von Ihnen erstellten Secret bereitstellen. Verweisen Sie anschließend in einer Ingress-Spezifikation auf das Secret, um einen HTTP(S)-Load-Balancer zu erstellen, der das Zertifikat verwendet. Weitere Informationen finden Sie in der Anleitung zur Verwendung von Zertifikaten in Secrets.

Systemdiagnosen

Wenn Sie einen oder mehrere Dienste über einen Ingress mithilfe des Standard-Ingress-Controllers verfügbar machen, erstellt GKE einen externen Google Cloud-HTTP(S)-Load-Balancer oder einen Google Cloud-internen HTTP(S)-Load-Balancer. Beide Load-Balancer unterstützen mehrere Back-End-Dienste für eine einzelne URL-Zuordnung. Jeder dieser Back-End-Dienste entspricht einem Kubernetes-Dienst und jeder Back-End-Dienst muss auf eine Google Cloud-Systemdiagnose verweisen. Diese Systemdiagnose unterscheidet sich von einer Kubernetes-Aktivitätsprüfung oder -Bereitschaftsprüfung, da die Systemdiagnose außerhalb des Clusters implementiert wird.

GKE erstellt anhand des folgenden Verfahrens eine Systemdiagnose für jeden Back-End-Dienst entsprechend einem Kubernetes-Service bereit:

  • Wenn der Dienst auf eine BackendConfig CRD mit healthCheck-Informationen verweist, verwendet GKE dies zum Erstellen der Systemdiagnose. Sowohl der Anthos Ingress-Controller als auch der GKE-Ingress-Controller unterstützen die Erstellung von Systemdiagnosen auf diese Weise.

  • Wenn der Service nicht auf eine BackendConfig-CRD verweist:

    • GKE kann einige oder alle Parameter für eine Systemdiagnose ableiten, wenn die Bereitstellungs-Pods eine Pod-Vorlage mit einem Container verwenden, dessen Bereitschaftsprüfung Attribute enthält, die als Systemdiagnoseparameter interpretiert werden können. Weitere Informationen zur Implementierung finden Sie unter Parameter aus einer Bereitschaftsprüfung. Unter Standardparameter und abgeleitete Parameter finden Sie eine Liste der Attribute, mit denen Systemdiagnoseparameter erstellt werden können. Nur der GKE-Ingress-Controller unterstützt das Ableiten von Parametern aus einer Bereitschaftsprüfung.

    • Wenn die Pod-Vorlage für die Bereitstellungs-Pods des Service keinen Container mit einer Bereitschaftsprüfung haben, deren Attribute als Systemdiagnoseparameter interpretiert werden können, werden die Standardwerte zum Erstellen der Systemdiagnose verwendet. Sowohl der Anthos Ingress-Controller als auch der GKE Ingress-Controller können eine Systemdiagnose erstellen, die nur die Standardwerte verwendet.

Standardparameter und abgeleitete Parameter

Die folgenden Parameter werden verwendet, wenn Sie keine Systemdiagnoseparameter für den entsprechenden Service mit einer BackendConfig-CRD angeben.

Systemdiagnoseparameter Standardwert Abgeleiteter Wert aus Bereitschaftsprüfung
Protokoll HTTP Falls im spec des Bereitstellungs-Pods vorhanden:
containers[].readinessProbe.httpGet.scheme
Anfragepfad / Falls im spec des Bereitstellungs-Pods vorhanden:
containers[].readinessProbe.httpGet.path
Host-Header anfordern Host: backend-ip-address Falls in den spec des Bereitstellungs-Pods vorhanden:
containers[].readinessProbe.httpGet.httpHeaders
Erwartete Antwort HTTP 200 (OK) HTTP 200 (OK)
kann nicht geändert werden
Prüfintervall
  • für zonale NEGs: 15 Sekunden
  • für Instanzgruppen: 60 Sekunden
Falls in den spec des Bereitstellungs-Pods vorhanden:
  • für zonale NEGs:
    containers[].readinessProbe.periodSeconds
  • für Instanzgruppen:
    containers[].readinessProbe.periodSeconds + 60 seconds
Zeitüberschreitung für Prüfung 5 Sekunden Falls in den spec des Bereitstellungs-Pods vorhanden:
containers[].readinessProbe.timeoutSeconds
Schwellenwert für Intaktheit 1 1
kann nicht geändert werden.
Fehlerschwellenwert
  • für zonale NEGs: 2
  • für Instanzgruppen: 10
entspricht dem Standardwert:
  • für zonale NEGs: 2
  • für Instanzgruppen: 10
Port
angegeben durch Nummer
  • für zonale NEGs: port des Service
  • für Instanzgruppen: der nodePort des Service
Wenn der backend.servicePort des Ingress-Objekts auf den port eines Service verweist, wird dieser Port verwendet, sofern Folgendes definiert ist:
  • Die Bereitschaftsprüfung des Bereitstellungs-Pods muss einen Port angeben:
    spec.containers[].readinessProbe.httpGet.port
  • Der targetPort des Service verweist auf den containers[].spec.ports.containerPort des Bereitstellungs-Pods
IP-Adresse des Ziels
  • für zonale NEGs: die IP-Adresse des Pods
  • für Instanzgruppen: die IP-Adresse des Knotens
entspricht dem Standardwert:
  • für zonale NEGs: die IP-Adresse des Pods
  • für Instanzgruppen: die IP-Adresse des Knotens

Parameter aus einer Bereitschaftsprüfung

Wenn GKE die Systemdiagnose für den Back-End-Dienst des Dienstes erstellt, kann GKE bestimmte Parameter aus der Bereitschaftsprüfung eines Containers kopieren, die von den Bereitstellungs-Pods jenes Dienstes verwendet wird. Diese Option wird nur vom GKE-Ingress-Controller unterstützt.

Unterstützte Attribute für Bereitschaftsprüfungen, die als Systemdiagnoseparameter interpretiert werden können, werden zusammen mit den Standardwerten unter Standardparameter und abgeleitete Parameter aufgelistet. Standardwerte werden für alle Attribute verwendet, die nicht in der Bereitschaftsprüfung angegeben sind, oder wenn Sie überhaupt keine Bereitschaftsprüfung angeben.

Wenn die Bereitstellungs-Pods für Ihren Service mehrere Container enthalten oder Sie den Anthos Ingress-Controller verwenden, sollten Sie Systemdiagnoseparameter mithilfe einer BackendConfig-CRD festlegen. Weitere Informationen finden Sie unter Wann sollte stattdessen eine BackendConfig-CRD verwendet werden?

Wann sollten stattdessen BackendConfig-CRDs verwendet werden?

Anstatt sich auf Parameter von Pod-Bereitschaftsprüfungen zu verlassen, sollten Sie Systemdiagnoseparameter für einen Back-End-Dienst explizit definieren, indem Sie in folgenden Situationen eine BackendConfig-CRD für den Service erstellen:

  • Wenn Sie Anthos verwenden: Der Anthos Ingress-Controller unterstützt nicht das Abrufen von Systemdiagnoseparametern aus den Bereitschaftsprüfungen von Bereitstellungs-Pods. Sie können Systemdiagnosen nur mit impliziten Parametern oder entsprechend der Definition in einer BackendConfig-CRD erstellen.

  • Wenn Bereitstellungs-Pods mehrere Container mit eindeutigen Bereitschaftsprüfungen haben: Wenn die Bereitstellungs-Pods für einen Service mehrere Container haben und jeder Container unterschiedliche Einstellungen für Bereitschaftsprüfungen hat, sollten Sie die Systemdiagnose für den entsprechenden Back-End-Dienst definieren. Dazu verweisen sie auf die BackendConfig-CRD des entsprechenden Service. Sie können in GKE keine bestimmte Bereitschaftsprüfung auswählen, von der Systemdiagnoseparameter abgeleitet werden, wenn im jeweiligen Bereitstellungs-Pod mehrere Bereitschaftsprüfungen vorhanden sind.

  • Wenn Sie den Port steuern möchten, der für die Systemdiagnosen des Load-Balancers verwendet wird: GKE verwendet für die Systemdiagnose des Back-End-Dienstes nur den containers[].readinessProbe.httpGet.port, wenn dieser mit dem Dienstport für den Service übereinstimmt, auf den im Ingress spec.rules[].http.paths[].backend.servicePort verwiesen wird.

Parameter aus einer BackendConfig-CRD

Sie können die Systemdiagnoseparameter des Back-End-Dienstes mithilfe des Parameters healthCheck eines BackendConfig-CRD angeben, auf den der entsprechende Dienst verweist. Dies gibt Ihnen mehr Flexibilität und Kontrolle über Systemdiagnosen für einen externen HTTP(S)-Load-Balancer von Google Cloud oder einen internen HTTP(S)-Load-Balancer, der von einem Ingress erstellt wurde. Weitere Informationen zur Kompatibilität der GKE-Versionen finden Sie unter Ingress-Features.

Diese BackendConfig-CRD definiert das Systemdiagnoseprotokoll (Typ), einen Anfragepfad, einen Port und ein Prüfintervall im zugehörigen Attribut spec.healthCheck:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Mehrere TLS-Zertifikate verwenden

Angenommen, Sie möchten, dass ein HTTP(S)-Load-Balancer Inhalte aus zwei Hostnamen bereitstellt: "your-store.example" und "your-experimental-store.example". Angenommen, Sie möchten auch, dass der Load-Balancer ein Zertifikat für "your-store.example" und ein anderes Zertifikat für "your-experimental-store.example" verwendet.

Dazu können Sie mehrere Zertifikate in einem Ingress-Manifest angeben. Der Load-Balancer wählt ein Zertifikat aus, wenn der allgemeine Name (Common Name, CN) im Zertifikat mit dem in der Anfrage verwendeten Hostnamen übereinstimmt. Ausführliche Informationen zum Konfigurieren mehrerer Zertifikate finden Sie unter Mehrere SSL-Zertifikate beim HTTPS-Load-Balancing mit Ingress verwenden.

Kubernetes-Dienst im Vergleich zum Google Cloud-Back-End-Dienst

Ein Kubernetes-Service ist etwas anderes als ein Google Cloud-Back-End-Dienst. Es gibt einen engen Zusammenhang zwischen beiden, aber ein Service und ein Dienst sind nicht in jedem Fall dasselbe. Der GKE-Ingress-Controller erstellt für jedes (serviceName, servicePort)-Paar in einem Ingress-Manifest einen Google Cloud-Back-End-Dienst. Daher kann ein Kubernetes-Service-Objekt mit mehreren Google Cloud-Back-End-Diensten verknüpft sein.

Beschränkungen

  • Die Gesamtlänge von Namespace und Name eines Ingress darf 40 Zeichen nicht überschreiten. Wird diese Regel nicht beachtet, kann es zu einem ungewöhnlichen Verhalten des GKE-Ingress-Controllers kommen. Weitere Informationen finden Sie auf GitHub unter diesem Thema.

  • Es gelten Kontingente für URL-Zuordnungen.

  • Wenn Sie keine NEGs mit dem GKE-Ingress-Controller verwenden, sind GKE-Cluster auf 1.000 Knoten begrenzt. Wenn Services mit NEGs bereitgestellt werden, gibt es kein Knotenlimit in GKE. Alle über Ingress bereitgestellten NEG-unabhängigen Services 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 dieser Problembeschreibung.

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

  • Ein externer HTTP(S)-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.

Nächste Schritte