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 Dienstobjekten zugeordnet. Diesen wiederum ist jeweils ein Satz 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:

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 dazu erhalten 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, 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, 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}'
...

Shared VPC

Ingress- und MultiClusterIngress-Ressourcen werden in Topologien freigegebener VPCs unterstützt, erfordern aber eine gewisse Vorbereitung. Die GKE-Ingress-Controller nutzen ein Google Cloud-Dienstkonto, um Google Cloud-Ressourcen bereitzustellen und zu verwalten. Wenn sich ein GKE-Cluster in einem Dienstprojekt einer freigegebenen VPC befindet, ist dieses Dienstkonto nicht berechtigt, Netzwerkressourcen des Hostprojekts zu verwalten. Der Ingress-Controller verwaltet Firewallregeln aktiv, um Zugriff zwischen Load-Balancern und Pods sowie zwischen zentralen Systemdiagnosen und Pods zu ermöglichen.

In einer freigegebenen VPC hat der GKE-Ingress-Controller jedoch keine Rechte zum Verwalten von Firewallregeln. Sie können Rechte hinzufügen und dafür manuell Firewallregeln aus dem Hostprojekt bereitstellen oder dem GKE-Ingress-Controller die Berechtigung erteilen, Firewallregeln von Hostprojekten zu verwalten.

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:

  • Gewähren Sie dem GKE-Dienstkonto des Dienstprojekts die Rolle Security Admin für das Hostprojekt. 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. Gewähren Sie dem GKE-Dienstkonto des Dienstprojekts diese benutzerdefinierte Rolle für das Hostprojekt.

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 Back-End-Dienste

Jeder externe 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 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/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. 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 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 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 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 diese 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 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
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 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 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 festlegen, auf den der entsprechende Dienst verweist. Dies gibt Ihnen mehr Flexibilität und Kontrolle über Systemdiagnosen für einen externen oder internen HTTP(S)-Load-Balancer von Google Cloud, der von einer Ingress-Ressource erstellt wird. 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

  • 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 auf GitHub unter diesem Thema.

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

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

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 Back-End-Dienst mit dem gleichen Namen erstellen, ist die GET-Anfrage erfolgreich, d. h. „Nicht gefunden“ wird nicht zurückzugeben.

Nächste Schritte