GKE Ingress-Routing und ‑Sicherheit

Auf dieser Seite werden die wichtigsten Funktionen und die Netzwerkarchitektur von GKE Ingress beschrieben, insbesondere das Sichern von Verbindungen vom Client zum Load Balancer und zu Anwendungs-Pods, das Verwalten komplexer Routings über mehrere Backend-Dienste hinweg und das Orchestrieren von Load-Balancer-Health-Checks in einem Cluster.

Diese Seite baut auf den grundlegenden Konzepten auf, die im GKE-Ingress-Überblick beschrieben werden. Eine detaillierte Anleitung und Implementierungsbeispiele mit benutzerdefinierten Ressourcen wie FrontendConfig und BackendConfig finden Sie unter Ingress-Features für GKE-Anwendungen konfigurieren.

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.

Ingress mit HTTPS sichern

GKE Ingress schützt den Traffic zwischen dem Client und dem Application Load Balancer sowie vom Load Balancer zu den Anwendungs-Pods.

TLS zwischen Client und Load Balancer konfigurieren

Ein HTTP(S)-Load-Balancer fungiert als Proxy zwischen Ihren Clients und Ihrer Anwendung. Wenn Sie HTTPS-Anfragen von Ihren Clients annehmen möchten, benötigt der Load-Balancer ein Zertifikat, damit er Ihren Clients seine Identität nachweisen kann. Der Load-Balancer benötigt außerdem einen privaten Schlüssel, um den HTTPS-Handshake abzuschließen.

Wenn der Load-Balancer eine HTTPS-Anfrage von einem Client akzeptiert, wird der Traffic zwischen dem Client und dem Load-Balancer mit TLS verschlüsselt. Der Load-Balancer beendet jedoch die TLS-Verschlüsselung und leitet die Anfrage ohne Verschlüsselung an die Anwendung weiter. Weitere Informationen finden Sie unter Verschlüsselung zwischen dem Load-Balancer und Ihrer Anwendung konfigurieren.

Methoden zum Bereitstellen von SSL-Zertifikaten

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

  • Von Google verwaltete Zertifikate: Diese DV-Zertifikate (Domain Validation) werden von Google für Ihre Domainnamen bereitgestellt, verlängert und verwaltet. Diese Zertifikate veranschaulichen nicht Ihre individuelle oder organisatorische Identität. Von Google verwaltete Zertifikate unterstützen bis zu 100 Domains ohne Platzhalter. Weitere Informationen finden Sie unter Von Google verwaltete Zertifikate verwenden.

  • Selbstverwaltete Zertifikate, die für Google Cloudfreigegeben sind: 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 unter Vorinstallierte Zertifikate verwenden.

  • Selbstverwaltete Zertifikate, die Kubernetes-Secrets verwenden: Sie können Ihr eigenes SSL-Zertifikat bereitstellen und ein Secret erstellen, in dem es gespeichert wird. Anschließend können Sie im Feld tls eines Ingress-Manifests auf das Secret verweisen, um einen HTTP(S)-Load-Balancer zu erstellen. Weitere Informationen finden Sie unter Kubernetes-Secrets verwenden.

HTTPS-Traffic mit mehreren Zertifikaten bereitstellen

Sie können den Application Load Balancer so konfigurieren, dass er einem Client bis zu 15 TLS-Zertifikate präsentiert. Die Verwendung von mehreren Zertifikaten ist unerlässlich, wenn Sie Inhalte von mehreren Hostnamen bereitstellen müssen, für die jeweils ein anderes Zertifikat erforderlich ist (z. B. separate Zertifikate für „your-store.example“ und „your-experimental-store.example“). Sie geben diese mehreren Zertifikate in Ihrem Ingress-Manifest an.

Zertifikatsauswahl und ‑priorität

Der Load-Balancer ermittelt mit „Server Name Indication“ (SNI), welches Zertifikat dem Client präsentiert werden soll.

  • Wenn der Client SNI verwendet oder einen Domainnamen, der mit dem Common Name (CN) in einem der verfügbaren Zertifikate übereinstimmt, verwendet der Load-Balancer das Zertifikat, dessen CN am besten mit dem vom Client angeforderten Hostnamen übereinstimmt.

  • Wenn der Client SNI nicht unterstützt oder der angeforderte Domainname nicht mit dem CN eines verfügbaren Zertifikats übereinstimmt, verwendet der Load-Balancer das erste im Ingress-Manifest aufgeführte Zertifikat als Standard. Der Load-Balancer wählt dieses Zertifikat entsprechend den folgenden Regeln aus:

    • Für die im Block tls aufgeführten Secrets ist das Hauptzertifikat das erste Secret im Block tls.
    • Bei vorinstallierten Zertifikaten in der Annotation pre-shared-cert ist das Hauptzertifikat das erste in der Annotation aufgeführte Zertifikat.
    • für von Google verwaltete Zertifikate in der Annotation managed-certificates: Alle verwalteten Zertifikate werden alphabetisch nach Namen sortiert. Das primäre Zertifikat ist das erste in dieser alphabetischen Liste. Wenn Sie ein bestimmtes Zertifikat als primäres Zertifikat festlegen möchten, müssen Sie Ihre ManagedCertificate-Objekte entsprechend benennen, um die Sortierreihenfolge zu steuern. Wenn Sie beispielsweise my-default-cert als primäre Variante gegenüber another-cert festlegen möchten, können Sie sie 0-my-default-cert und 1-another-cert nennen.

Wenn der Load-Balancer mehrere Zertifikate über verschiedene GKE-Methoden präsentiert, haben vorinstallierte Zertifikate Vorrang vor Secrets, die im Ingress-Block tls aufgeführt sind.

Das folgende Diagramm zeigt den Load Balancer, der Traffic an verschiedene Backends sendet, je nach dem in der Anfrage verwendeten Domainnamen:

Mehrere SSL-Zertifikate mit Ingress – Systemdiagramm

Best Practices für die Zertifikatsrotation

Wenn Sie den Inhalt Ihres Secret- oder vorinstallierten Zertifikats rotieren möchten, beachten Sie dazu die folgenden Best Practices:

  • Erstellen Sie ein neues Secret oder ein vorinstalliertes Zertifikat mit einem anderen Namen, das die neuen Zertifikatsdaten enthält. Aktualisieren Sie Ihren Ingress, damit die neue Zertifikatsressource verwendet wird.
  • Wenn die Unterbrechung des Traffics kein Problem ist, können Sie die alte Ressource aus dem Ingress-Objekt entfernen, eine neue Ressource mit dem gleichen Namen, aber mit anderem Inhalt bereitstellen und sie dann wieder an das Ingress-Objekt anhängen.

Wenn Sie die Zertifikatsrotation nicht selbst verwalten möchten, verwenden Sie von Google verwaltete SSL-Zertifikate.

Nur-HTTPS-Traffic erzwingen

Wenn der gesamte Traffic zwischen dem Client und dem HTTP(S)-Load-Balancer HTTPS verwenden soll, können Sie HTTP deaktivieren. Dazu nehmen Sie die Anmerkung kubernetes.io/ingress.allow-http in Ihr Ingress-Manifest auf und setzen den Wert auf "false". Weitere Informationen finden Sie unter HTTP deaktivieren.

Verschlüsselung zwischen dem Load-Balancer und Ihrer Anwendung konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Verbindung vom Load Balancer zu den Anwendungs-Pods schützen.

HTTPS- oder HTTP/2-Backend-Protokoll aktivieren

Der externe Application Load Balancer fungiert als Proxy zwischen Ihren Clients und Ihrer GKE-Anwendung. Clients können zwar über HTTPS (zur Verschlüsselung) und verschiedene Protokolle (HTTP/1.1 oder HTTP/2) eine Verbindung zum Load-Balancer herstellen, die Verbindung vom Load-Balancer zu Ihren Backend-Pods erfolgt jedoch standardmäßig über unverschlüsseltes HTTP/1.1.

Wenn Ihre Anwendung erweiterte Konfigurationen verarbeiten kann, können Sie den externen Application Load Balancer manuell aktualisieren, um Folgendes zu verwenden:

  • HTTP/2: zur Optimierung der Leistung, wenn Ihre Pods dies unterstützen.
  • HTTPS (TLS): um die End-to-End-Verschlüsselung für den Traffic zwischen dem Load-Balancer-Proxy und Ihren Pods zu erzwingen.

Sie steuern sowohl das Protokoll (HTTP oder HTTPS) als auch die HTTP-Version (HTTP/1.1 oder HTTP/2), die für die Backend-Verbindung verwendet wird, mit der Annotation cloud.google.com/app-protocols in Ihrem Kubernetes-Dienstmanifest. Dieses Dienstmanifest muss type: NodePort enthalten, sofern Sie nicht containernatives Load-Balancing verwenden. Wenn Sie containernatives Load-Balancing verwenden, verwenden Sie type: ClusterIP.

Statische IP-Adressen für HTTP(S)-Load-Balancer

Wenn Sie ein Ingress-Objekt für einen externen Application Load Balancer erstellen, erhalten Sie eine stabile externe IP-Adresse, über die Clients auf Ihre Dienste und Ihre laufenden Container zugreifen können. Die IP-Adresse ist in dem Sinne stabil, als sie für die Lebensdauer des Ingress-Objekts gilt. Wenn Sie Ihr Ingress löschen und ein neues Ingress aus derselben Manifestdatei erstellen, wird nicht garantiert, dass Sie dieselbe externe IP-Adresse erhalten.

Wenn Sie beim Löschen Ihrer Ingress-Adresse und beim Erstellen einer neuen Adresse eine dauerhafte IP-Adresse beibehalten möchten, müssen Sie eine globale statische externe IP-Adresse reservieren. Fügen Sie dann in Ihrem Ingress-Manifest eine Anmerkung hinzu, die den Namen Ihrer reservierten statischen IP-Adresse angibt. Wenn Sie eine vorhandene Ingress-Ressource so ändern, dass eine statische IP-Adresse anstelle einer sitzungsspezifischen IP-Adresse verwendet wird, ändert GKE möglicherweise die IP-Adresse des Load-Balancers, wenn GKE die Weiterleitungsregel des Load-Balancers neu erstellt.

Traffic weiterleiten

GKE Ingress verwendet URL-Zuordnungen, um zu definieren, wie eingehende Anfragen an bestimmte Back-End-Dienste weitergeleitet werden. Sie können Routingregeln basierend auf Hostnamen, URL-Pfaden oder einer Kombination aus beidem konfigurieren, um den Traffic für mehrere Anwendungen über einen einzelnen Load Balancer zu verwalten.

Mehrere Back-End-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.

Wenn Sie GKE Ingress mit mehreren Backends für denselben Host konfigurieren möchten, müssen Sie eine einzelne Regel mit einem einzelnen Host und mehreren Pfaden haben. Andernfalls stellt der GKE-Ingress-Controller nur einen Backend-Dienst bereit.

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:
  - host: your-store.example
    http:
      paths:
      - path: /products
        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/products sendet, wird die Anfrage an einen Kubernetes-Dienst mit dem Namen my-products an Port 60000 weitergeleitet. Wenn ein Client eine Anfrage an your-store.example/discounted sendet, wird die Anfrage an einen Kubernetes-Dienst mit dem Namen 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-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

Beachten Sie im vorherigen Manifest Folgendes:

  • Das Feld spec.type hängt von der verwendeten Load-Balancing-Methode ab:

  • Im Feld selector wird angegeben, dass jeder Pod mit den beiden Labels app: products und department: sales ein Mitglied dieses Dienstes 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

Beachten Sie im vorherigen Manifest Folgendes:

  • Im Feld selector wird angegeben, dass jeder Pod, der sowohl das Label app: discounted-products als auch das Label department: sales hat, Mitglied dieses Dienstes 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 benutzerdefinierten Standard-Backend finden Sie unter GKE Ingress mit benutzerdefiniertem Standard-Backend.

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

Load-Balancer-Systemdiagnosen werden pro Backend-Dienst angegeben. While it's possible to use the same health check for all backend services of the load balancer, the health check reference isn't specified for the whole load balancer (at the Ingress object itself).

GKE erstellt Systemdiagnosen anhand einer der folgenden Methoden:

  • BackendConfig-CRD: Eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD), mit der Sie genau steuern können, wie Ihre Dienste mit dem Load Balancer interagieren. Mit BackendConfig-CRDs können Sie benutzerdefinierte Einstellungen für die Systemdiagnose des entsprechenden Back-End-Dienstes angeben. Diese benutzerdefinierten Einstellungen bieten mehr Flexibilität und Kontrolle über Systemdiagnosen für den klassischen Application Load Balancer und den internen Application Load Balancer, die von einem Ingress erstellt werden.
  • Bereitschaftsprüfung: Eine Diagnoseprüfung, mit der ermittelt wird, ob ein Container in einem Pod bereit ist, Traffic zu verarbeiten. Der GKE-Ingress-Controller erstellt die Systemdiagnose für den Back-End-Dienst des Dienstes anhand der Bereitschaftsprüfung, die von den Bereitstellungs-Pods dieses Dienstes verwendet wird. Sie können die Systemdiagnoseparameter wie Pfad, Port und Protokoll aus der Definition der Readiness-Probe ableiten.
  • Standardwerte: Die Parameter, die verwendet werden, wenn Sie keine BackendConfig-CRD konfigurieren oder keine Attribute für die Bereitschaftsprüfung definieren.
Best Practice:

Verwenden Sie eine BackendConfig-CRD, um die Einstellungen für die Load-Balancer-Systemdiagnose am besten steuern zu können.

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 containernatives Load-Balancing: 15 Sekunden
  • für Instanzgruppen: 60 Sekunden
 Falls in den spec des Bereitstellungs-Pods vorhanden:
  • für containernatives Load-Balancing:
    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 containernatives Load-Balancing: 2
  • für Instanzgruppen: 10
 entspricht dem Standardwert:
  • für containernatives Load-Balancing: 2
  • für Instanzgruppen: 10
Portspezifikation
  • Für containernatives Load-Balancing: die port des Dienstes
  • 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 containernatives Load-Balancing: die IP-Adresse des Pods
  • für Instanzgruppen: Die IP-Adresse des Knotens
 entspricht dem Standardwert:
  • für containernatives Load-Balancing: 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 das Abrufen von Systemdiagnoseparametern aus den Bereitschaftsprüfungen von Bereitstellungs-Pods nicht. 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.

Pod-Bereitschaft

Nachdem die Systemdiagnosen des Load-Balancers mit einer der oben genannten Methoden konfiguriert wurden, verwendet der GKE Ingress-Controller den Systemdiagnosestatus der Back-End-Endpunkte, um die Pod-Bereitschaft zu bestimmen. Dies ist entscheidend für die Verwaltung von Rolling Updates und die allgemeine Traffic-Stabilität.

Für relevante Pods verwaltet der entsprechende Ingress-Controller ein Readiness-Gate vom Typ cloud.google.com/load-balancer-neg-ready. Der Ingress-Controller fragt den Status der Systemdiagnose des Load-Balancers ab, einschließlich der Zustände aller Endpunkte in der NEG. Wenn der Status der Systemdiagnose des Load-Balancers anzeigt, dass der einem bestimmten Pod entsprechende Endpunkt fehlerfrei ist, setzt der Ingress-Controller den Wert des Readiness-Gates des Pods auf True. Das Kubelet, das auf jedem Knoten ausgeführt wird, berechnet dann die tatsächliche Bereitschaft des Pods. Dafür wird sowohl der Wert des Readiness-Gates berücksichtigt als auch die Bereitschaftsprüfung des Pods, sofern diese definiert wurde.

Pod-Readiness-Gates werden bei Verwendung von containernativem Load-Balancing über Ingress automatisch aktiviert.

Mit Readiness-Gates wird die Rate von Rolling Updates gesteuert. Wenn Sie ein Rolling Update initiieren, wird für jeden neuen, von GKE erstellten Pod ein Endpunkt zu einer NEG hinzugefügt. Wenn der Endpunkt aus der Sicht des Load-Balancers fehlerfrei ist, setzt der Ingress-Controller das Readiness-Gate auf True. Es muss mindestens das Readiness-Gate des neu erstellten Pods den Status "True" haben, bevor GKE einen alten Pod entfernt. Dadurch wird sichergestellt, dass der dem Pod entsprechende Endpunkt bereits die Systemdiagnose des Load-Balancers bestanden hat und dass die Back-End-Kapazität beibehalten wird.

Wenn das Readiness-Gate eines Pods aufgrund eines fehlerhaften Container-Images oder einer falsch konfigurierten Load-Balancer-Systemdiagnose nicht angibt, dass der Pod bereit ist, leitet der Load-Balancer keinen Traffic an den neuen Pod weiter. Tritt ein solcher Fehler beim Einführen eines aktualisierten Deployments auf, wird die Einführung nach dem Versuch, einen neuen Pod zu erstellen, angehalten, da das Readiness-Gate dieses Pods nie den Status "True" aufweist. Informationen dazu, wie Sie herausfinden können, ob dieses Problem vorliegt und wie Sie es beheben können, finden Sie im Abschnitt "Fehlerbehebung".

Ohne containernatives Load-Balancing und Readiness-Gates kann GKE nicht feststellen, ob die Endpunkte eines Load-Balancers fehlerfrei sind, bevor GKE die entsprechenden Pods als bereit markiert. Bei älteren Kubernetes-Versionen haben Sie die Rate, mit der Pods entfernt und ersetzt werden, gesteuert, indem Sie in der Deployment-Spezifikation mit minReadySeconds eine Verzögerung angegeben haben.

GKE setzt den Wert von cloud.google.com/load-balancer-neg-ready für einen Pod auf True, wenn eine der folgenden Bedingungen erfüllt ist:

  • Keine der IP-Adressen des Pods ist ein Endpunkt, der in einer GCE_VM_IP_PORT-NEG gespeichert ist, die von der GKE-Steuerungsebene verwaltet wird.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer GCE_VM_IP_PORT-NEG, die von der GKE-Steuerungsebene verwaltet wird. Die NEG ist mit einem Backend-Dienst verknüpft. Der Backend-Dienst hat eine erfolgreiche Systemdiagnose für den Load-Balancer.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer GCE_VM_IP_PORT-NEG, die von der GKE-Steuerungsebene verwaltet wird. Die NEG ist mit einem Backend-Dienst verknüpft. Bei der Systemdiagnose des Load-Balancers für den Backend-Dienst tritt eine Zeitüberschreitung auf.
  • Eine oder mehrere IP-Adressen des Pods sind Endpunkte in einer oder mehreren GCE_VM_IP_PORT-NEGs. Keine der NEGs ist an einen Backend-Dienst angehängt. Es sind keine Daten zur Load-Balancer-Systemdiagnose verfügbar.

Unterstützung von WebSocket

Bei externen Application Load Balancern funktioniert das WebSocket-Protokoll ohne Konfiguration.

Wenn Sie das WebSocket-Protokoll verwenden, können Sie für das Zeitlimit einen Wert festlegen, der größer als der Standardwert von 30 Sekunden ist. Beim Senden von WebSocket-Traffic an einen externen Application Load Balancer vonGoogle Cloud wird das Zeitlimit für den Back-End-Dienst als die maximale Zeit verstanden, die eine WebSocket-Verbindung geöffnet sein kann – im Leerlauf oder aktiv.

Informationen zum Festlegen des Zeitlimitwerts für einen Back-End-Dienst finden Sie unter Zeitlimit für Back-End-Antwort.

Erweiterte Netzwerkszenarien

GKE Ingress unterstützt erweiterte Netzwerkkonfigurationen wie die gemeinsame Nutzung von Netzwerkressourcen über Projekte hinweg und die Verwendung benutzerdefinierter Ingress-Controller.

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:

Wenn Ihre Sicherheitsrichtlinien nur die Firewallverwaltung des Hostprojekts zulassen, können Sie diese Firewallregeln manuell bereitstellen. Wenn Sie Ingress in einer freigegebene 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 vonGoogle Cloud -Systemdiagnosen.

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, compute.firewalls.delete und compute.subnetworks.list. 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

Ersetzen Sie dabei Folgendes:

Benutzerdefinierten Ingress-Controller verwenden

Sie können einen benutzerdefinierten Ingress-Controller ausführen, indem Sie das Add-on HttpLoadBalancing deaktivieren. Dadurch wird verhindert, dass der GKE-Ingress-Controller Ingress-Ressourcen verarbeitet.

Wenn Sie einen benutzerdefinierten Ingress-Controller mit dem aktivierten Add-on HttpLoadBalancing ausführen möchten, beispielsweise um Features wieUntereinstellung und Private Service Connect zu verwenden, können Sie einen der folgenden Ansätze verwenden:

Achten Sie darauf, dass spec.ingressClassName nicht versehentlich von einem Prozess überschrieben wird. Ein Aktualisierungsvorgang, bei dem spec.IngressClassName von einem gültigen Wert in einen leeren String ("") geändert wird, führt dazu, dass der GKE-Ingress-Controller das Ingress verarbeitet.

Feld ingressClassName konfigurieren

Sie können einen benutzerdefinierten Ingress-Controller verwenden, indem Sie das Feld ingressClassName im Ingress-Manifest festlegen. Das folgende Manifest beschreibt ein Ingress, das den cilium-Ingress-Controller angibt:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

Standard-Ingress-Klasse konfigurieren

Sie können eine Standard-Ingress-Klasse für alle Ingress-Ressourcen in einem Cluster konfigurieren. Dazu erstellen Sie eine IngressClass-Ressource, bei der die Annotation ingressclass.kubernetes.io/is-default-class auf true festgelegt ist.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

Verhaltens des GKE-Ingress-Controllers

Ob der GKE-Ingress-Controller bei Clustern der GKE-Version 1.18 oder höher ein Ingress verarbeitet, hängt vom Wert der Annotation kubernetes.io/ingress.class und vom Feld ingressClassName im Ingress-Manifest ab. Weitere Informationen finden Sie unter Verhalten des GKE-Ingress-Controllers.

Vorlagen für die Ingress-Konfiguration