GKE Ingress für Application Load Balancer

Auf dieser Seite erhalten Sie eine allgemeine Übersicht über die Funktionsweise von Ingress für externe Application Load Balancer. 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.

Überblick

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. Weitere Informationen dazu, wie Ingress Anwendungen mithilfe von Services bereitstellt, finden Sie unter Überblick über das Servicenetzwerk.

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:

Verhalten des GKE-Ingress-Controllers

Bei Clustern mit GKE-Versionen 1.18 und höher hängt es vom Wert der Annotation kubernetes.io/ingress.class ab, ob der GKE-Ingress-Controller einen Ingress verarbeitet oder nicht:

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.

Bei Clustern mit älteren GKE-Versionen verarbeitet der GKE-Controller jedes Ingress, das die Annotation kubernetes.io/ingress.class nicht oder mit dem Wert gce oder gce-internal hat.

Einstellung der Annotation kubernetes.io/ingress.class

Obwohl die Annotation kubernetes.io/ingress.class in Kubernetes verworfen wurde, verwendet GKE diese Annotation weiterhin.

Sie können das Feld ingressClassName nicht verwenden, um eine GKE-Ingress-Ressource anzugeben. Sie müssen die Annotation kubernetes.io/ingress.class verwenden.

Features externer Application Load Balancer

Ein von Ingress konfigurierter externer Application Load Balancer enthält 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 dazu erhalten Sie unter Ingress-Konfiguration.

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, auf denen Container dieselbe Hostschnittstelle nutzen, führt dies zu bestimmten 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
  • Freigegebene VPC nicht verwenden
  • GKE-Netzwerkrichtlinie nicht verwenden

Unter diesen Bedingungen werden Dienste automatisch mit cloud.google.com/neg: '{"ingress": true}' annotiert. Dies legt fest, dass eine NEG erstellt werden soll, um die Pod-IP-Adressen innerhalb des Dienstes zu spiegeln. Mithilfe der 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, nicht automatisch vom Dienstüberwacher annotiert werden.

Bei GKE 1.17.6-gke.7+ und früher mit automatischer NEG-Annotation können NEGs deaktiviert werden und der externe Compute Engine-Load-Balancer kann gezwungen werden, bei Bedarf eine Instanzgruppe als Back-Ends zu verwenden. Dazu annotieren Sie Services explizit mit cloud.google.com/neg: '{"ingress": false}'. NEGs mit Ingress für interne Application Load Balancer können nicht deaktiviert werden.

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

Freigegebene VPC

Ingress- und MultiClusterIngress-Ressourcen werden in der freigegebenen VPC unterstützt, erfordern jedoch eine zusätzliche Vorbereitung.

Der Ingress-Controller wird auf der GKE-Steuerungsebene ausgeführt und führt über das GKE-Dienstkonto des Projekts des Clusters API-Aufrufe an Google Cloud durch. Wenn ein Cluster in einem Dienstprojekt einer freigegebenen VPC ein freigegebenes VPC-Netzwerk verwendet, kann der Ingress-Controller standardmäßig nicht das GKE-Dienstkonto des Dienstprojekts verwenden, um Firewallregeln zum Zulassen von eingehendem Traffic in dem Hostprojekt zu erstellen.

Sie können dem GKE-Dienstkonto des Dienstprojekts die Berechtigung erteilen, VPC-Firewallregeln im Hostprojekt zu verwalten und zu erstellen. Durch das Gewähren dieser Berechtigungen erstellt GKE Firewallregeln zum Zulassen von eingehendem Traffic für Folgendes:

Firewallregeln aus dem Hostprojekt manuell bereitstellen

Wenn Ihre Sicherheitsrichtlinien nur die Firewallverwaltung des Hostprojekts zulassen, können Sie diese Firewallregeln manuell bereitstellen. Wenn Sie Ingress in einer freigegebenen VPC bereitstellen, enthält das Ingress-Ressourcenereignis die jeweilige Firewallregel, die Sie für den Zugriff hinzufügen müssen.

So stellen Sie eine Regel manuell bereit:

  1. Rufen Sie das Ingress-Ressourcenereignis auf:

    kubectl describe ingress INGRESS_NAME

    Ersetzen Sie INGRESS_NAME durch Ihren Ingress-Namen.

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

    Die vorgeschlagene erforderliche Firewallregel wird in der Spalte Message angezeigt.

  2. Kopieren Sie die vorgeschlagenen Firewallregeln aus dem Hostprojekt und wenden Sie sie an. Die Anwendung der Regeln ermöglicht Zugriff auf die Pods vom Load-Balancer und von Google Cloud-Systemdiagnosen.

GKE Ingress-Controller-Berechtigung zum Verwalten von Firewallregeln des Hostprojekts bereitstellen

Wenn Sie möchten, dass ein GKE-Cluster in einem Dienstprojekt die Firewallressourcen in Ihrem Hostprojekt erstellt und verwaltet, müssen Sie dem GKE-Dienstkonto des Dienstprojekts die entsprechenden IAM-Berechtigungen mithilfe einer der folgenden Strategien erteilen:

  • Weisen Sie dem GKE-Dienstkonto des Dienstprojekts die Rolle „Compute-Sicherheitsadministrator“ für das Hostprojekt zu. Das folgende Beispiel veranschaulicht diese Strategie.

  • Für einen detaillierteren Ansatz erstellen Sie eine benutzerdefinierte IAM-Rolle, die nur die folgenden Berechtigungen enthält: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update und compute.firewalls.delete. Weisen Sie dem GKE-Dienstkonto des Dienstprojekts diese benutzerdefinierte Rolle im Hostprojekt zu.

Wenn Sie Cluster in mehr als einem Dienstprojekt haben, müssen Sie eine der Strategien auswählen und für das GKE-Dienstkonto jedes Dienstprojekts wiederholen.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Dabei gilt:

Mehrere Backend-Dienste

Jeder externe oder interne Application Load Balancer verwendet eine einzelne URL-Zuordnung, die auf einen oder mehrere Backend-Dienste verweist. Ein Backend-Dienst entspricht dem jeweiligen 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/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

Wenn Sie das Ingress-Objekt erstellt haben, erstellt und konfiguriert der GKE-Ingress-Controller einen externen Application Load Balancer oder einen internen Application 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. Beispielsweise sind /*, /foo/* und /foo/bar/* 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-Dienst 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 für Ihr Ingress angeben, indem Sie in Ihrem Ingress-Manifest das Feld spec.defaultBackend ausfüllen. Alle Anfragen, die nicht mit den im Feld rules definierten Pfaden übereinstimmen, werden verarbeitet. Zum Beispiel werden im folgenden Ingress alle Anfragen, die nicht mit /discounted oder my-products übereinstimmen, an einen Dienst namens an Port 60001 gesendet.

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

Wenn Sie kein Standard-Back-End angeben, stellt GKE ein Standard-Back-End bereit, das den Fehler 404 zurückgibt. Dieses wird als default-http-backend-NodePort-Dienst im Cluster im Namespace kube-system erstellt.

Die HTTP-Antwort 404 sieht etwa so aus:

response 404 (backend NotFound), service rules for the path non-existent

Informationen zum Einrichten von GKE Ingress mit einem Standard-Backend für Kunden finden Sie unter GKE Ingress mit benutzerdefiniertem Standard-Backend.

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.

Bereitstellungsoptionen für SSL-Zertifikate

Sie können einem HTTP(S)-Load-Balancer mit den folgenden Methoden SSL-Zertifikate 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 Services über einen Ingress mithilfe des Standard-Ingress-Controllers verfügbar machen, erstellt GKE einen klassischen Application Load Balancer oder einen internen Application Load Balancer. Beide Load-Balancer unterstützen mehrere Backend-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 diese zum Erstellen der Systemdiagnose. Sowohl der GKE Enterprise 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 GKE Enterprise-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 Ableitbarer Wert
Protokoll HTTP Falls in der Dienstannotation cloud.google.com/app-protocols vorhanden
Anfragepfad / Falls in den 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
Portspezifikation
  • für zonale NEGs: port des Service
  • für Instanzgruppen: der nodePort des Service
 Die Systemdiagnoseprüfungen werden an die durch spec.containers[].readinessProbe.httpGet.port angegebene Portnummer gesendet, sofern alle folgenden Bedingungen erfüllt sind:
  • Die Portnummer der Bereitschaftsprüfung stimmt mit dem containers[].spec.ports.containerPort des Bereitstellungs-Pods überein.
  • Der containerPort des Bereitstellungs-Pods entspricht dem targetPort des Service.
  • Die Ingress-Dienst-Backend-Portspezifikation verweist auf einen gültigen Port aus spec.ports[] des Dienstes. Dazu gibt es zwei Möglichkeiten:
    • spec.rules[].http.paths[].backend.service.port.name im Ingress stimmt mit spec.ports[].name überein, das im entsprechenden Service definiert ist.
    • spec.rules[].http.paths[].backend.service.port.number im Ingress stimmt mit spec.ports[].port überein, das im entsprechenden Service definiert ist.
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 die Systemdiagnose für den Back-End-Dienst des Dienstes mit GKE erstellt wird, kann GKE bestimmte Parameter aus der Bereitschaftsprüfung eines Containers kopieren, die von Bereitstellungs-Pods dieses 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 wenn Sie den GKE Enterprise-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 GKE Enterprise verwenden: Der GKE Enterprise 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 Sie mehrere Container in den Bereitstellungs-Pods haben: GKE bietet keine Möglichkeit, die Bereitschaftsprüfung eines bestimmten Containers auszuwählen, um daraus Systemdiagnose-Parameter abzuleiten. Da jeder Container eine eigene Bereitschaftsprüfung haben kann und eine Bereitschaftsprüfung kein erforderlicher Parameter für einen Container ist, sollten Sie die Systemdiagnose für den entsprechenden Backend-Dienst definieren, indem Sie auf eine BackendConfig-CRD für den entsprechenden Service verweisen.

  • Wenn Sie den Port steuern möchten, der für die Systemdiagnosen des Load-Balancers verwendet wird: GKE verwendet für die Systemdiagnose des Backend-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 Backend-Dienstes mithilfe des Parameters healthCheck eines BackendConfig-CRD festlegen, auf den der entsprechende Dienst verweist. So erhalten Sie mehr Flexibilität und Kontrolle über Systemdiagnosen für einen klassischen Application Load Balancer oder einen internen Application Load Balancer, der von einem Ingress erstellt wurde. Weitere Informationen zur Kompatibilität der GKE-Versionen finden Sie unter Ingress-Konfiguration.

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

Verwenden Sie das Beispiel für die Konfiguration einer benutzerdefinierten Systemdiagnose, um alle Felder zu konfigurieren, die beim Konfigurieren einer BackendConfig-Systemdiagnose verfügbar sind.

Informationen zum Einrichten von GKE Ingress mit einer benutzerdefinierten HTTP-Systemdiagnose finden Sie unter GKE Ingress mit benutzerdefinierter HTTP-Systemdiagnose.

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 (service.name, service.port)-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

  • Bei Clustern mit Versionen vor 1.16 darf die Gesamtlänge des Namespace und des Namens eines Ingress 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 in diesem GitHub-Problemkommentar zu langen Namen.

  • 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 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 diesem GitHub-Problemkommentar zu Systemdiagnosen.

  • Änderungen an der readinessProbe eines Pods wirken sich nicht auf Ihr Ingress aus, nachdem es 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.

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.

Details zur Implementierung

  • Der Ingress-Controller führt regelmäßig Prüfungen der Dienstkontoberechtigungen aus. Dazu wird eine Testressource aus Ihrem Google Cloud-Projekt abgerufen. Dies wird als GET-Anfrage des (nicht vorhandenen) globalen BackendService-Objekts mit dem Namen k8s-ingress-svc-acct-permission-check-probe angegeben. Da diese Ressource normalerweise nicht vorhanden ist, gibt die GET-Anfrage „Nicht gefunden“ zurück. Dies so vorgesehen. Der Controller prüft, ob der API-Aufruf aufgrund von Autorisierungsproblemen abgelehnt wurde. Wenn Sie einen Backend-Dienst mit dem gleichen Namen erstellen, ist die GET-Anfrage erfolgreich, d. h. „Nicht gefunden“ wird nicht zurückzugeben.

Vorlagen für die Ingress-Konfiguration

Nächste Schritte