Ingress configuration on Google Cloud

Diese Seite bietet eine umfassende Übersicht über die in Google Cloud unterstützten und konfigurierbaren Einstellungen von Kubernetes Ingress.

Funktionsvergleich

Die folgende Tabelle enthält eine Liste der in Google Cloud unterstützten Features für Ingress. Die Verfügbarkeit der Funktion, General Availability (GA) oder Beta, wird ebenfalls angegeben.

Ingress-Klasse Externer Ingress Interner Ingress Multi-Cluster-Ingress
Ingress-Controller Von Google gehosteter Ingress-Controller GKE-Ingress-Controller
Typ des Google Cloud-Load-Balancers Externer HTTP(S)-Load-Balancer Interner HTTP(S)-Load-Balancer Externer HTTP(S)-Load-Balancer
Clusterbereich Einzelner Cluster Einzelner Cluster Multi-Cluster
Load-Balancer-Bereich Global Regional Global
Umgebungsunterstützung GKE GKE GKE
Unterstützung für freigegebene VPC AV AV AV
Dienstannotationen
Containernatives Load-Balancing (NEGs) GA GA GA
HTTPS vom Load-Balancer zu Back-Ends GA AV GA
HTTP/2 GA GA
Nur TLS		 GA
Ingress-Annotationen
Statische IP-Adressen GA GA GA
Auf Secrets beruhende Kubernetes-Zertifikate GA GA GA
Selbstverwaltete SSL-Zertifikate GA GA GA
Von Google verwaltete SSL-Zertifikate GA GA
FrontendConfig
SSL-Richtlinie GA GA mit Gateway GA
HTTP-zu-HTTPS-Weiterleitung GA
1.17.13-gke.2600+G		 GA
BackendConfig
Zeitlimit für Back-End-Dienst GA GA GA
Cloud CDN GA GA
Zeitlimit für Verbindungsausgleich GA GA GA
Benutzerdefinierte Konfiguration Load-Balancer-Systemdiagnosen GA GA GA
Google Cloud Armor-Sicherheitsrichtlinie GA
1.19.10-gke.700G		 GA
Konfiguration des HTTP-Zugriffs-Loggings GA GA GA
Identity-Aware Proxy (IAP) GA GA GA
Sitzungsaffinität GA GA GA
Benutzerdefinierte Anfrageheader GA GA
Benutzerdefinierte Antwortheader GA GA

B Dieses Feature ist in der Betaversion ab der angegebenen Version verfügbar. Features ohne aufgeführte Version werden für alle verfügbaren GKE- und GKE Enterprise-Versionen unterstützt.

G Dieses Feature wird als GA ab der angegebenen Version unterstützt.

Ingress mit dem Standardcontroller konfigurieren

Sie können LoadBalancer-Features nicht manuell mit dem Google Cloud SDK oder der Google Cloud Console konfigurieren. Sie müssen BackendConfig- oder FrontendConfig-Kubernetes-Ressourcen verwenden.

Wenn Sie einen Ingress mit dem Standardcontroller erstellen, können Sie den Typ des Load-Balancers (einen externen Anwendungs-Load-Balancer oder einen internen Anwendungs-Load-Balancer) mithilfe einer Annotation für das Ingress-Objekt auswählen. Sie können auswählen, ob GKE zonale NEGs erstellt oder Instanzgruppen verwendet, indem Sie für jedes Dienstobjekt eine Annotation verwenden.

Mithilfe von benutzerdefinierten Ressourcendefinitionen (CDRs) für FrontendConfig und BackendConfig können Sie den Load-Balancer weiter anpassen. Mit diesen CRDs können Sie zusätzliche Features des Load-Balancers hierarchischer definieren als Annotationen. Damit Sie Ingress (und diese CRDs) verwenden können, muss das HTTP-Load-Balancing-Add-on aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.

FrontendConfigs werden in einem Ingress-Objekt referenziert und können nur mit externen Ingress-Objekten verwendet werden. BackendConfigs werden von einem Dienstobjekt referenziert. Dieselben CRDs können aus Gründen der Konfigurationskonsistenz von mehreren Dienst- oder Ingress-Objekten referenziert werden. Die FrontendConfig- und BackendConfig-CRDs haben den gleichen Lebenszyklus wie die entsprechenden Ingress- und Dienstressourcen und werden häufig zusammen bereitgestellt.

Dies wird im folgenden Diagramm veranschaulicht:

  • Eine Annotation zu einem Ingress- oder MultiClusterIngress-Objekt verweist auf eine FrontendConfig-CRD. Die FrontendConfig-CRD verweist auf eine Google Cloud-SSL-Richtlinie.

  • Eine Annotation zu einem Dienst- oder MultiClusterService-Objekt verweist auf eine BackendConfig-CRD. Die BackendConfig-CRD gibt benutzerdefinierte Einstellungen für die Systemdiagnose des entsprechenden Back-End-Dienstes an.

Übersicht zu BackendConfig und FrontendConfig
Abbildung: Übersicht zu BackendConfig und FrontendConfig

FrontendConfig mit Ihrem Ingress verknüpfen

FrontendConfig kann nur mit externen Ingress-Objekten verwendet werden.

Sie können eine FrontendConfig mit einem Ingress oder einem MultiClusterIngress verknüpfen.

Eingehender Traffic

Verwenden Sie die Annotation networking.gke.io/v1beta1.FrontendConfig:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

Ersetzen Sie FRONTENDCONFIG_NAME durch den Namen Ihrer FrontendConfig.

MultiClusterIngress

Verwenden Sie die Annotation networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

Ersetzen Sie FRONTENDCONFIG_NAME durch den Namen Ihrer FrontendConfig.

BackendConfig mit Ihrem Ingress verknüpfen

Sie können die Annotation cloud.google.com/backend-config oder beta.cloud.google.com/backend-config verwenden, um den Namen einer BackendConfig anzugeben.

Gleiche BackendConfig für alle Service-Ports

Verwenden Sie in der Annotation den Schlüssel default, um für alle Ports dieselbe BackendConfig zu verwenden. Der Ingress-Controller verwendet jedes Mal, wenn er einen Load-Balancer-Backend-Dienst zu erstellt, dieselbe BackendConfig, um auf einen der Ports des Service zu verweisen.

Sie können den Schlüssel default sowohl für Ingress- als auch für MultiClusterIngress-Ressourcen verwenden. 
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Eindeutige BackendConfig pro Service-Port

Sowohl für Ingress als auch für MultiClusterIngress können Sie eine benutzerdefinierte BackendConfig für einen oder mehrere Ports angeben, indem Sie einen Schlüssel verwenden, der mit dem Namen oder der Nummer des Ports übereinstimmt. Der Ingress-Controller verwendet die spezifische BackendConfig, wenn er einen Load-Balancer-Backend-Dienst für einen referenzierten Service-Port erstellt.

GKE 1.16-gke.3 und höher

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Alle unterstützten Versionen

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Dabei gilt:

  • BACKENDCONFIG_REFERENCE_A: der Name einer vorhandenen BackendConfig-Ressource.
  • BACKENDCONFIG_REFERENCE_B: der Name einer vorhandenen BackendConfig-Ressource.
  • SERVICE_REFERENCE_A: Verwenden Sie den Wert von PORT_NUMBER_1 oder PORT_NAME_1. Dies liegt daran, dass die BackendConfig-Annotation eines Service entweder auf den Namen des Ports (spec.ports[].name) oder die Nummer des Ports (spec.ports[].port) verweisen kann.
  • SERVICE_REFERENCE_B: Verwenden Sie den Wert von PORT_NUMBER_2 oder PORT_NAME_2. Dies liegt daran, dass die BackendConfig-Annotation eines Service entweder auf den Namen des Ports (spec.ports[].name) oder die Nummer des Ports (spec.ports[].port) verweisen kann.

Wenn Sie den Port des Service über die Nummer angeben, müssen Sie den Wert port anstelle des Werts targetPort verwenden. Die hier verwendete Portnummer dient nur zum Binden der BackendConfig. Der Port, an den der Load-Balancer Traffic oder Systemdiagnoseprüfungen sendet, wird nicht festgelegt:

  • Wenn Sie das containernative Load-Balancing verwenden, sendet der Load-Balancer Traffic an einen Endpunkt in einer Netzwerk-Endpunktgruppe (die einer Pod-IP-Adresse entspricht) am targetPort des referenzierten Service-Ports (der einem containerPort für einen Bereitstellungs-Pod entsprechen muss). Andernfalls sendet der Load-Balancer Traffic an die IP-Adresse eines Knotens am nodePort des referenzierten Service-Ports.

  • Wenn Sie eine BackendConfig verwenden, um eine benutzerdefinierte Load-Balancer-Systemdiagnose bereitzustellen, kann die Portnummer, die Sie für die Systemdiagnose des Load-Balancers verwenden, von der spec.ports[].port-Nummer des Service abweichen. Weitere Informationen zu Portnummern für Systemdiagnosen finden Sie unter Benutzerdefinierte Systemdiagnosekonfiguration.

Ingress-Features über FrontendConfig-Parameter konfigurieren

Im folgenden Abschnitt erfahren Sie, wie Sie Ihre FrontendConfig so konfigurieren, dass bestimmte Ingress-Features aktiviert werden.

SSL-Richtlinien

Mit SSL-Richtlinien können Sie eine Reihe von TLS-Versionen und -Chiffren angeben, mit denen der Load-Balancer den HTTPS-Traffic von Clients beendet. Sie müssen zuerst außerhalb von GKE eine SSL-Richtlinie erstellen. Danach können Sie in einer FrontendConfig-CRD darauf verweisen.

Das Feld sslPolicy in FrontendConfig verweist auf den Namen einer SSL-Richtlinie im selben Google Cloud-Projekt wie der GKE-Cluster. Die SSL-Richtlinie wird an den Ziel-HTTPS-Proxy angehängt, der vom Ingress für den externen HTTP(S)-Load-Balancer erstellt wurde. Mehrere Ingress-Ressourcen können auf dieselbe FrontendConfig-Ressource und dieselbe SSL-Richtlinie verweisen. Wenn eine referenzierte SSL-Richtlinie geändert wird, wird die Änderung an die Google Front Ends (GFEs) übertragen, die Ihren vom Ingress erstellten externen HTTP(S)-Load-Balancer unterstützen.

Das folgende FrontendConfig-Manifest aktiviert eine SSL-Richtlinie mit dem Namen gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

HTTP-zu-HTTPS-Weiterleitungen

Ein externer HTTP-Load-Balancer kann unverschlüsselte HTTP-Anfragen an einen HTTPS-Load-Balancer weiterleiten, der dieselbe IP-Adresse verwendet. Wenn Sie ein Ingress mit HTTP-zu-HTTPS-Weiterleitungen erstellen, werden beide Load-Balancer automatisch erstellt. Anfragen an die externe IP-Adresse des Ingress an Port 80 werden automatisch an dieselbe externe IP-Adresse an Port 443 umgeleitet. Diese Funktion basiert auf HTTP-zu-HTTPS-Weiterleitungen, die durch Cloud Load Balancing bereitgestellt werden.

Damit die HTTP-zu-HTTPS-Weiterleitung unterstützen wird, muss ein Ingress konfiguriert werden, um sowohl HTTP- als auch HTTPS-Traffic bereitzustellen. Ist HTTP oder HTTPS deaktiviert, funktioniert die Weiterleitung nicht.

HTTP-zu-HTTPS-Weiterleitungen werden in einer benutzerdefinierten FrontendConfig-Ressource mit dem Feld redirectToHttps konfiguriert. Weiterleitungen sind für die gesamte Ingress-Ressource aktiviert, sodass für alle Dienste, auf die vom Ingress verwiesen wird, HTTPS-Weiterleitungen aktiviert sind.

Das folgende FrontendConfig-Manifest aktiviert HTTP-zu-HTTPS-Weiterleitungen. Setzen Sie das Feld spec.redirectToHttps.enabled auf true, um HTTPS-Weiterleitungen zu aktivieren. Das Feld spec.responseCodeName ist optional. Wenn es weggelassen wird, wird eine 301-Moved Permanently-Umleitung verwendet.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

Ersetzen Sie RESPONSE_CODE durch einen der folgenden Werte:

  • MOVED_PERMANENTLY_DEFAULT, um einen Weiterleitungs-Antwortcode 301 zurückzugeben (Standardwert, wenn responseCodeName nicht angegeben ist).
  • FOUND, um einen Weiterleitungs-Antwortcode 302 zurückzugeben.
  • SEE_OTHER, um einen Weiterleitungs-Antwortcode 303 zurückzugeben.
  • TEMPORARY_REDIRECT, um einen Weiterleitungs-Antwortcode 307 zurückzugeben.
  • PERMANENT_REDIRECT, um einen Weiterleitungs-Antwortcode 308 zurückzugeben.

Wenn Weiterleitungen aktiviert sind, erstellt der Ingress-Controller einen Load-Balancer, wie im folgenden Diagramm dargestellt:

Ein externer Nur-Weiterleitungs-HTTP-Load-Balancer, der aus einer Weiterleitungsregel, einem Ziel-HTTP-Proxy und einer URL-Zuordnung mit einer Weiterleitung zu einem vollständigen HTTPS-Load-Balancer mit Backend-Diensten besteht

Prüfen Sie mit einem curl-Befehl, ob Ihre Weiterleitung funktioniert:

curl http://IP_ADDRESS

Ersetzen Sie IP_ADDRESS durch die IP-Adresse Ihres Ingress.

In der Antwort wird der von Ihnen konfigurierte Weiterleitungsantwortcode angezeigt. Das folgende Beispiel bezieht sich auf eine FrontendConfig, die mit einer Weiterleitung vom Typ 301: MovedPermanently konfiguriert ist:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

Ingress-Features über BackendConfig-Parameter konfigurieren

In den folgenden Abschnitten wird gezeigt, wie Sie Ihre BackendConfig festlegen, um bestimmte Ingress-Features zu aktivieren. Änderungen an einer BackendConfig-Ressource werden ständig abgeglichen, sodass Sie Ihren Ingress nicht löschen und neu erstellen müssen, um zu sehen, dass BackendConfig-Änderungen übernommen werden.

Informationen zu BackendConfig-Einschränkungen finden Sie im Abschnitt Einschränkungen.

Zeitüberschreitung von Back-End-Dienst

Sie können mit BackendConfig ein Zeitlimit für den Back-End-Dienst in Sekunden festlegen. Wenn Sie keinen Wert angeben, beträgt der Standardwert 30 Sekunden.

Das folgende BackendConfig-Manifest gibt ein Zeitlimit von 40 Sekunden an:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Sie können Cloud CDN mit einer BackendConfig aktivieren.

Das folgende BackendConfig-Manifest zeigt alle verfügbaren Felder, wenn Cloud CDN aktiviert wird:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

Ersetzen Sie Folgendes:

  • CDN_ENABLED: Wenn dieser Wert auf true gesetzt ist, wird Cloud CDN für dieses Ingress-Back-End aktiviert.
  • INCLUDE_HOST: Wenn dieser Wert auf true gesetzt ist, werden Anfragen an verschiedene Hosts getrennt im Cache gespeichert.
  • INCLUDE_PROTOCOL: Wenn dieser Wert auf true gesetzt ist, werden HTTP- und HTTPS-Anfragen getrennt im Cache gespeichert.
  • INCLUDE_QUERY_STRING: Wenn dieser Wert auf true gesetzt ist, sind Abfragestringparameter gemäß queryStringBlacklist oder queryStringWhitelist im Cache-Schlüssel enthalten. Wenn weder das eine noch das andere Feld festgelegt ist, wird der gesamte Abfragestring einbezogen. Bei false wird der gesamte Abfragestring aus dem Cache-Schlüssel ausgeschlossen.
  • QUERY_STRING_DENYLIST: Geben Sie ein String-Array mit den Namen von Abfragestringparametern an, die von Cache-Schlüsseln ausgeschlossen werden sollen. Alle anderen Parameter werden einbezogen. Sie können queryStringBlacklist oder queryStringWhitelist angeben, aber nicht beide.
  • QUERY_STRING_ALLOWLIST: Geben Sie ein String-Array mit den Namen der Abfragestringparameter an, die in Cache-Schlüssel einbezogen werden sollen. Alle anderen Parameter werden ausgeschlossen. Sie können queryStringBlacklist oder queryStringWhitelist angeben, aber nicht beide.

Die folgenden Felder werden nur in GKE-Versionen ab 1.23.3-gke.900 mit GKE Ingress unterstützt. Sie werden nicht mithilfe von Multi-Cluster-Ingress unterstützt:

Erweitern Sie den folgenden Abschnitt, um ein Beispiel zu sehen, in dem Cloud CDN über Ingress bereitgestellt und dann validiert wird, dass die Anwendungsinhalte im Cache gespeichert werden.

Zeitlimit für Verbindungsausgleich

Sie können ein Zeitlimit für den Verbindungsausgleich mit einer BackendConfig konfigurieren. Das Zeitlimit für den Verbindungsausgleich ist die Zeit in Sekunden, die gewartet wird, bis die Verbindung beendet wird. Für die angegebene Dauer des Zeitlimits werden bestehende Anfragen an das Back-End, das entfernt wurde, abgeschlossen. Der Load-Balancer sendet keine neuen Anfragen an das entfernte Back-End. Nach Ablauf des Zeitlimits werden alle verbleibenden Verbindungen zum Back-End geschlossen. Das Zeitlimit kann zwischen 0 und 3.600 Sekunden liegen. Der Standardwert ist 0, wodurch auch der Verbindungsausgleich deaktiviert wird.

Das folgende BackendConfig-Manifest gibt ein Zeitlimit von 60 Sekunden für den Verbindungsausgleich an:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Benutzerdefinierte Konfiguration für Systemdiagnosen

GKE bietet bei der Bereitstellung über Ingress verschiedene Methoden zur Konfiguration von Systemdiagnosen für den Google Cloud-Load-Balancer. Weitere Informationen zur Bereitstellung von Systemdiagnosen durch GKE Ingress finden Sie unter Ingress-Systemdiagnosen.

Mit einer BackendConfig können Sie die Einstellungen für die Load-Balancer-Systemdiagnose genau steuern.

Sie können mehrere GKE-Dienste so konfigurieren, dass sie auf dieselbe BackendConfig als wiederverwendbare Vorlage verweisen. Bei healthCheck-Parametern wird für jeden Backend-Dienst, der einzelnen GKE-Diensten entspricht, eine eindeutige Google Cloud-Systemdiagnose erstellt.

Das folgende BackendConfig-Manifest zeigt alle verfügbaren Felder, wenn eine BackendConfig-Systemdiagnose konfiguriert wird:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    type: PROTOCOL
    requestPath: PATH
    port: PORT

Ersetzen Sie Folgendes:

  • INTERVAL: Geben Sie für alle Systemdiagnose-Prober den check-interval in Sekunden an. Dies ist die Zeit vom Beginn der Prüfung eines Probers bis zum Start der nächsten Prüfung. Wenn Sie diesen Parameter weglassen, wird der Google Cloud-Standardwert von 5 Sekunden verwendet. Weitere Implementierungsdetails finden Sie unter Mehrere Prüfungen und Häufigkeit.
  • TIMEOUT: Geben Sie an, wie lange Google Cloud bei einer Prüfung auf eine Antwort wartet. Der Wert von TIMEOUT muss kleiner oder gleich dem von INTERVAL sein. Die Einheit sind Sekunden. Bei jeder Prüfung muss vor Ablauf des Zeitlimits ein HTTP 200 (OK)-Antwortcode gesendet werden.
  • HEALTH_THRESHOLD und UNHEALTHY_THRESHOLD: Geben Sie die Anzahl der aufeinanderfolgenden Verbindungsversuche an, die für mindestens einen Prober erfolgreich oder fehlgeschlagen sein müssen, um den Systemstatus von "fehlerfrei" in "fehlerhaft" oder umgekehrt zu ändern. Wenn Sie einen dieser Parameter weglassen, verwendet Google Cloud den Standardwert 2.
  • PROTOCOL: Geben Sie ein Protokoll an, das von Prüfsystemen für Systemdiagnosen verwendet wird. Die BackendConfig unterstützt nur das Erstellen von Systemdiagnosen mit den Protokollen HTTP, HTTPS oder HTTP2. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP, HTTPS und HTTP/2. Sie können diesen Parameter nicht weglassen.
  • PATH: Geben Sie für HTTP-, HTTPS- oder HTTP2-Systemdiagnosen den request-path an, zu dem das Prüfsystem eine Verbindung herstellen soll. Wenn Sie diesen Parameter weglassen, verwendet Google Cloud den Standardwert /.

  • PORT: Eine BackendConfig unterstützt nur die Angabe des Ports für die Load-Balancer-Systemdiagnose mithilfe einer Portnummer. Wenn Sie diesen Parameter weglassen, verwendet Google Cloud den Standardwert 80.

    • Wenn Sie das containernative Load-Balancing verwenden, sollten Sie einen Port auswählen, der mit einem containerPort eines Bereitstellungs-Pods übereinstimmt (unabhängig davon, ob auf den containerPort durch einen targetPort des Service verwiesen wird). Da der Load-Balancer Prüfungen direkt an die IP-Adresse des Pods sendet, sind Sie nicht auf containerPorts beschränkt, auf die vom targetPort eines Service verwiesen wird. Prüfsysteme für die Systemdiagnose stellen über den von Ihnen angegebenen Port eine Verbindung zur IP-Adresse eines bereitstellenden Pods her.

    • Für Instanzgruppen-Back-Ends müssen Sie einen Port auswählen, der mit einem vom Service bereitgestellten nodePort übereinstimmt. Prüfsysteme für die Systemdiagnose stellen dann eine Verbindung zu jedem Knoten an diesem Port her.

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

Ingress-Sicherheitsrichtlinie für Google Cloud Armor

Mit den Google Cloud Armor-Sicherheitsrichtlinien können Sie Ihre Anwendungen mit Load-Balancing vor Angriffen aus dem Web schützen. Wenn Sie eine Google Cloud Armor-Sicherheitsrichtlinie konfiguriert haben, können Sie mit einer BackendConfig darauf verweisen.

Fügen Sie der BackendConfig den Namen Ihrer Sicherheitsrichtlinie hinzu. Das folgende BackendConfig-Manifest gibt eine Sicherheitsrichtlinie mit dem Namen example-security-policy an:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Zwei Quellen der Wahrheit

Obwohl die zugrunde liegenden BackendService APIs von Compute Engine über GKE konfiguriert wurden, können Sie weiterhin direkt ändern, welche Sicherheitsrichtlinie angewendet werden soll. Dadurch werden zwei "Sources of Truth" erstellt: GKE und Compute Engine. Das Verhalten des GKE-Ingress-Controllers als Reaktion auf das Feld securityPolicy in BackendConfig ist in der folgenden Tabelle dokumentiert. Zur Vermeidung von Konflikten und unerwartetem Verhalten empfehlen wir die Verwendung des GKE-BackendConfig, um zu verwalten, welche Sicherheitsrichtlinie verwendet werden soll.

Feld "BackendConfig" Wert Verhalten
spec.securityPolicy.name CloudArmorPolicyName Der GKE Ingress-Controller legt die Google Cloud Armor-Richtlinie namens CloudArmorPolicyName auf den Load-Balancer fest. Der GKE-Ingress-Controller überschreibt die zuvor festgelegte Richtlinie.
spec.securityPolicy.name Leerer String ("") Der GKE Ingress-Controller entfernt alle konfigurierten Google Cloud Armor-Richtlinien aus dem Load-Balancer.
spec.securityPolicy nil Der GKE-Ingress-Controller verwendet die für das BackendService-Objekt festgelegte Konfiguration, die über die Compute Engine API mit der Google Cloud Console, der gcloud CLI oder Terraform konfiguriert wurde.

Informationen zum Einrichten von GKE Ingress mit Google Cloud Armor-Schutz finden Sie unter Google Cloud Armor-fähiger Ingress.

HTTP-Zugriffs-Logging

Ingress kann alle HTTP-Anfragen von Clients in Cloud Logging protokollieren. Sie können das Zugriffs-Logging mit BackendConfig aktivieren und deaktivieren und die Stichprobenrate für das Zugriffs-Logging festlegen.

Verwenden Sie das Feld logging in Ihrer BackendConfig, um das Zugriffs-Logging zu konfigurieren. Wenn logging weggelassen wird, verwendet das Zugriffs-Logging das Standardverhalten. Dies hängt von der GKE-Version ab.

Sie können folgende Felder konfigurieren:

  • enable: Wenn dieser Wert auf true gesetzt ist, wird das Zugriffs-Logging für diesen Ingress aktiviert und Logs sind in Cloud Logging verfügbar. Andernfalls ist das Zugriffs-Logging für diesen Ingress deaktiviert.
  • sampleRate: Geben Sie einen Wert zwischen 0,0 und 1,0 an, wobei 0,0 bedeutet, dass keine Pakete protokolliert, und 1,0, dass 100 % der Pakete protokolliert werden. Dieses Feld ist nur relevant, wenn enable auf true gesetzt ist. sampleRate ist ein optionales Feld. Wenn es jedoch konfiguriert ist, muss auch enable: true festgelegt werden, da es andernfalls als enable: false interpretiert wird.

Mit dem folgenden BackendConfig-Manifest wird das Zugriffs-Logging aktiviert und die Abtastrate auf 50 % der HTTP-Anfragen für eine bestimmte Ingress-Ressource festgelegt:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Zur Konfiguration der BackendConfig für Identity-Aware Proxy IAP müssen Sie die Werte enabled und secretName für den Block iap in Ihrer BackendConfig angeben. Sie benötigen die Berechtigung compute.backendServices.update, um diese Werte anzugeben.

Das folgende BackendConfig-Manifest aktiviert Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

IAP mit dem von Google verwalteten OAuth-Client aktivieren

Ab GKE 1.29.2-gke.1035000 kann IAP zur Verwendung des von Google verwalteten OAuth-Clients mit einer BackendConfig konfiguriert werden. Informationen dazu, ob Sie den Google OAuth-Client oder einen benutzerdefinierten OAuth-Client verwenden möchten, finden Sie in der IAP-Dokumentation unter Wann ist eine benutzerdefinierte OAuth-Konfiguration zu verwenden..

Geben Sie die OAuthCredentials nicht in der BackendConfig an, um IAP mit dem von Google verwalteten OAuth-Client zu aktivieren. Für Nutzer, die IAP bereits mit OAuthCredentials konfiguriert haben, gibt es keinen Migrationspfad, um zur Verwendung des Google Managed OAuth-Clients zu wechseln. Sie müssen das Back-End neu erstellen (den Dienst aus dem Ingress entfernen und wieder anhängen). Wir empfehlen, diesen Vorgang während eines Wartungsfensters auszuführen, da dies zu Ausfallzeiten führt. Umgekehrter Migrationspfad, der Wechsel von Google Managed OAuthClient zu OAuthCredentials ist möglich.

Das folgende BackendConfig-Manifest aktiviert Identity-Aware Proxy mit dem von Google verwalteten OAuth-Client: 

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

Eine vollständige Anleitung finden Sie in der IAP-Dokumentation unter IAP für GKE aktivieren.

Identity-Aware Proxy mit internem Ingress

Zum Konfigurieren des internen Ingress für IAP müssen Sie die Premium-Stufe verwenden. Wenn Sie die Premium-Stufe nicht verwenden, können Sie keine internen Anwendungs-Load-Balancer mit Identity-Aware Proxy anzeigen oder erstellen. Außerdem benötigen Sie ein BeyondCorp Enterprise-Abo, um den internen Ingress für IAP verwenden zu können.

Informationen zum Einrichten von sicherem GKE-Ingress mit Identity-Aware Proxy-basierter Authentifizierung finden Sie unter IAP-fähiger Ingress.

Sitzungsaffinität

Mit einer BackendConfig können Sie die Client-IP oder das generierte Cookie für die Sitzungsaffinität festlegen.

Client-IP-Affinität

Wenn Sie mit einer BackendConfig die Client-IP-Affinität festlegen möchten, legen Sie affinityType wie im folgenden Beispiel auf "CLIENT_IP" fest:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Wenn Sie eine BackendConfig verwenden möchten, um die generierte Cookie-Affinität festzulegen, setzen Sie affinityType in Ihrem BackendConfig-Manifest auf GENERATED_COOKIE. Sie können auch affinityCookieTtlSec verwenden, um den Zeitraum festzulegen, für den das Cookie aktiv bleibt.

Das folgende Manifest legt den Affinitätstyp auf ein generiertes Cookie fest und weist den Cookies eine TTL von 50 Sekunden zu:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Benutzerdefinierte Anfrageheader

Mit BackendConfig lassen sich benutzerdefinierte Anfrage-Header konfigurieren. Der Load-Balancer fügt die von Ihnen angegebenen Header den Anfragen hinzu, die er an die Back-Ends weiterleitet.

Zum Aktivieren benutzerdefinierter Anfrageheader geben Sie im Attribut customRequestHeaders der BackendConfig-Ressource eine Liste von Headern an. Geben Sie jeden Header als header-name:header-value-String an.

Das folgende BackendConfig-Manifest fügt drei Anfrage-Header hinzu:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Benutzerdefinierte Antwortheader

Zum Aktivieren benutzerdefinierter Antwortheader geben Sie im Attribut customResponseHeaders der BackendConfig-Ressource eine Liste von Headern an. Geben Sie jeden Header als header-name:header-value-String an.

Das folgende BackendConfig-Manifest ist ein Beispiel für das Hinzufügen eines HSTS-Antwortheaders (HTTP Strict Transport Security):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

Übung: Ingress-Zeitlimits mit einem Back-End-Dienst festlegen

Die folgende Übung zeigt die Schritte, die zum Konfigurieren von Zeitlimits und eines Verbindungsausgleich mit einer Ingress-Ressource mit einer BackendConfig-Ressource erforderlich sind.

Führen Sie die folgenden Aufgaben aus, um die Back-End-Attribute einer Ingress-Ressource zu konfigurieren:

  1. Erstellen Sie ein Deployment.
  2. Erstellen Sie eine BackendConfig.
  3. Erstellen Sie einen Service und verknüpfen Sie einen seiner Ports mit der BackendConfig-Ressource.
  4. Erstellen Sie ein Ingress und ordnen Sie das Ingress dem Paar (Dienst, Port) zu.
  5. Prüfen Sie die Attribute des Back-End-Dienstes.
  6. Führen Sie eine Bereinigung durch.

Deployment erstellen

Erstellen Sie zuerst ein Deployment, bevor Sie eine BackendConfig und einen Dienst erstellen.

Das folgende Beispielmanifest gilt für ein Deployment mit dem Namen my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Erstellen Sie das Deployment mit dem folgenden Befehl:

kubectl apply -f my-deployment.yaml

BackendConfig-Ressource erstellen

Verwenden Sie Ihre BackendConfig, um die Ingress-Feature anzugeben, die Sie verwenden möchten.

Das BackendConfig-Manifest my-backendconfig.yaml gibt Folgendes an:

  • ein Zeitlimit von 40 Sekunden
  • ein Zeitlimit für Verbindungsausgleich von 60 Sekunden
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Erstellen Sie die BackendConfig mit dem folgenden Befehl:

kubectl apply -f my-backendconfig.yaml

Dienst erstellen

Eine BackendConfig entspricht einer einzelnen Dienst-Port-Kombination, auch wenn ein Dienst mehrere Ports hat. Jeder Port kann einer einzelnen BackendConfig-CRD zugeordnet werden. Wenn ein Ingress auf einen Dienstport verweist und der Dienstport einer BackendConfig zugeordnet ist, übernimmt der Back-End-Dienst für HTTP(S)-Load-Balancing seine Konfiguration teilweise aus der BackendConfig.

Das folgende Beispiel zeigt das Dienstmanifest my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

Die Annotation cloud.google.com/backend-config gibt eine Zuordnung zwischen Ports und BackendConfig-Objekten an. In my-service.yaml:

  • Jeder Pod mit dem Label purpose: bsc-config-demo ist ein Mitglied des Dienstes.
  • TCP-Port 80 des Dienstes ist einem BackendConfig-Objekt mit dem Namen my-backendconfig zugeordnet. Dies wird durch die Annotation cloud.google.com/backend-config angegeben.
  • Eine an Port 80 des Dienstes gesendete Anfrage wird an einen der Mitglieds-Pods an Port 8080 weitergeleitet.

Führen Sie den folgenden Befehl aus, um den Dienst zu erstellen:

kubectl apply -f my-service.yaml

Ingress erstellen

Im Folgenden sehen Sie ein Ingress-Manifest namens my-ingress.yaml.. In diesem Beispiel werden eingehende Anfragen an Port 80 des Dienstes my-service weitergeleitet.

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

Führen Sie den folgenden Befehl aus, um das Ingress zu erstellen:

kubectl apply -f my-ingress.yaml

Warten Sie einige Minuten, bis der Ingress-Controller einen externen Anwendungs-Load-Balancer und einen zugehörigen Backend-Dienst konfiguriert hat. Sobald dies abgeschlossen ist, haben Sie Ihr Ingress so konfiguriert, dass ein Zeitlimit von 40 Sekunden und ein Zeitlimit für den Verbindungsausgleich von 60 Sekunden verwendet wird.

Attribute des Back-End-Dienstes prüfen

Sie können prüfen, ob die Einstellungen für den Load-Balancer über Ihre BackendConfig-Ressource angewendet wurden. Ermitteln Sie dazu den Back-End-Dienst, den das Ingress bereitgestellt hat, und prüfen Sie, ob die Einstellungen mit den Deployment-Manifesten übereinstimmen.

Beschreiben Sie zuerst die Ressource my-ingress und den Filter für die Annotation, die die mit dem Ingress verknüpften Back-End-Dienste auflistet. Beispiel:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Die Ausgabe sollte in etwa so aussehen:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

Die Ausgabe enthält Informationen zu Ihren Back-End-Diensten. Diese Annotation enthält beispielsweise zwei Back-End-Dienste:

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" provides information about the backend service associated with the my-service Kubernetes Service.
    • k8s1-27fde173 ist ein Hash, mit dem der Cluster beschrieben wird.
    • default ist der Kubernetes-Namespace.
    • HEALTHY gibt an, dass das Back-End fehlerfrei ist.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" provides information about the backend service associated with the default backend (404-server).
    • k8s1-27fde173 ist ein Hash, mit dem der Cluster beschrieben wird.
    • kube-system ist der Namespace.
    • default-http-backend ist der Name des Kubernetes-Dienstes.
    • 80 ist der Hostport.
    • HEALTHY gibt an, dass das Back-End fehlerfrei ist.

Prüfen Sie als Nächstes den Back-End-Dienst für my-service mithilfe von gcloud. Filtern Sie nach "drainingTimeoutSec" und "timeoutSec", um zu bestätigen, dass sie in der Steuerungsebene des Google Cloud-Load-Balancers festgelegt wurden. Beispiel:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Ausgabe:

  drainingTimeoutSec: 60
  timeoutSec: 40

Wenn Sie drainingTimeoutSec und timeoutSec in der Ausgabe sehen, bestätigen Sie, dass ihre Werte über die BackendConfig korrekt festgelegt wurden.

Bereinigen

Um unerwünschte Kosten für Ihr Konto zu vermeiden, löschen Sie die Kubernetes-Objekte, die Sie für diese Übung erstellt haben:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

BackendConfig-Beschränkungen

Für BackendConfigs gelten die folgenden Einschränkungen:

  • Ein Dienst/Port-Paar kann nur eine BackendConfig verwenden, auch wenn mehrere Ingress-Objekte auf das Dienst/Port-Paar verweisen. Dies bedeutet, dass alle Ingress-Objekte, die auf dasselbe Dienst/Port-Paar verweisen, dieselbe Konfiguration für Google Cloud Armor, IAP und Cloud CDN verwenden müssen.
  • IAP und Cloud CDN können nicht für denselben Back-End-Dienst für das HTTP(S) Load Balancing aktiviert werden. Dies bedeutet, dass sich IAP und Cloud CDN nicht im selben BackendConfig-Objekt konfigurieren lassen.
  • Zur Interaktion mit BackendConfig benötigen Sie kubectl ab Version 1.7.

Die in einer FrontendConfig oder BackendConfig angegebene Konfiguration entfernen

Wenn Sie ein Ingress-Feature entfernen möchten, müssen Sie die Featurekonfiguration in der FrontendConfig- oder BackendConfig-CRD explizit deaktivieren. Der Ingress-Controller gleicht nur die in diesen CRDs angegebenen Konfigurationen ab.

Zum Löschen oder Deaktivieren einer zuvor aktivierte Konfiguration setzen Sie den Wert des Felds je nach Feldtyp auf einen leeren String ("") oder auf einen booleschen Wert von false.

Das folgende BackendConfig-Manifest deaktiviert eine Google Cloud Armor-Sicherheitsrichtlinie und Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

FrontendConfig oder BackendConfig löschen

FrontendConfig

So löschen Sie eine FrontendConfig:

  1. Entfernen Sie im Ingress-Manifest den Namen der FrontendConfig aus der Annotation networking.gke.io/v1beta1.FrontendConfig.

  2. Wenden Sie das geänderte Ingress-Manifest auf Ihren Cluster an. Verwenden Sie zum Beispiel kubectl apply.

  3. Löschen Sie die FrontendConfig. Verwenden Sie zum Beispiel kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

So löschen Sie ein BackendConfig-Objekt:

  1. Entfernen Sie den Namen des BackendConfig-Objekts aus der Annotation cloud.google.com/backend-config im Dienstmanifest.

  2. Wenden Sie das geänderte Dienstmanifest auf Ihren Cluster an. Verwenden Sie zum Beispiel kubectl apply.

  3. Löschen Sie die BackendConfig. Verwenden Sie zum Beispiel kubectl delete backendconfig my-backendconfig.

Fehlerbehebung

Sie können gängige Fehlkonfigurationen mit dem Diagnosetool für Ingress erkennen. Achten Sie außerdem darauf, dass alle Systemdiagnosen korrekt konfiguriert sind.

BackendConfig wurde nicht gefunden

Dieser Fehler tritt auf, wenn in der Dienstannotation eine BackendConfig-Ressource für einen Dienstport angegeben wurde, die eigentliche BackendConfig-Ressource jedoch nicht gefunden werden konnte.

Führen Sie den folgenden Befehl aus, um ein Kubernetes-Ereignis auszuwerten:

kubectl get event

Die folgende Ausgabe zeigt an, dass Ihre BackendConfig nicht gefunden wurde:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Achten Sie zur Behebung dieses Problems darauf, dass Sie die BackendConfig-Ressource nicht im falschen Namespace erstellt oder ihren Verweis in der Dienstannotation falsch geschrieben haben.

Ingress-Sicherheitsrichtlinie nicht gefunden

Wenn die Sicherheitsrichtlinie nach der Erstellung des Ingress-Objekts nicht ordnungsgemäß dem Load-Balancer-Dienst zugeordnet wird, sollten Sie das Kubernetes-Ereignis auf Konfigurationsfehler prüfen. Wenn Ihre BackendConfig eine Sicherheitsrichtlinie angibt, die nicht vorhanden ist, wird regelmäßig ein Warnungsereignis ausgegeben.

Führen Sie den folgenden Befehl aus, um ein Kubernetes-Ereignis auszuwerten:

kubectl get event

Die folgende Ausgabe zeigt an, dass Ihre Sicherheitsrichtlinie nicht gefunden wurde:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Geben Sie zur Behebung dieses Problems den richtigen Namen der Sicherheitsrichtlinie in Ihrer BackendConfig an.

500er-Fehler bei NEGs während der Arbeitslastskalierung in GKE beheben

Symptom:

Wenn Sie von GKE bereitgestellte NEGs für das Load-Balancing verwenden, können während des Herunterskalierens der Arbeitslast 502- oder 503-Fehler für die Dienste auftreten. 502-Fehler treten auf, wenn Pods beendet werden, bevor vorhandene Verbindungen geschlossen werden. Die 503-Fehler treten auf, wenn Traffic an gelöschte Pods weitergeleitet wird.

Dieses Problem kann Cluster betreffen, wenn Sie in GKE verwaltete Load-Balancing-Produkte verwenden, die NEGs verwenden, einschließlich Gateway, Ingress und eigenständige NEGs. Wenn Sie Ihre Arbeitslasten häufig skalieren, besteht ein höheres Risiko, dass sie betroffen sind.

Diagnose:

Das Entfernen eines Pods in Kubernetes, ohne seinen Endpunkt zu leeren und ihn aus der NEG zu entfernen, führt zu 500-Fehlern. Wenn Sie Probleme während der Beendigung des Pods vermeiden möchten, müssen Sie die Reihenfolge der Vorgänge berücksichtigen. Die folgenden Abbildungen zeigen Szenarien, wenn BackendService Drain Timeout nicht festgelegt und BackendService Drain Timeout mit BackendConfig festgelegt ist.

Szenario 1: BackendService Drain Timeout ist nicht festgelegt.

Die folgende Abbildung zeigt ein Szenario, in dem BackendService Drain Timeout nicht festgelegt ist.

Zeitlimit für BackendService-Drain wird nicht festgelegt

Szenario 2: BackendService Drain Timeout ist festgelegt.

In der folgenden Abbildung sehen Sie ein Szenario, in dem BackendService Drain Timeout festgelegt wird.

Zeitlimit für Back-End-Drain ist festgelegt

Die genaue Zeit, zu der die 500er-Fehler auftreten, hängt von folgenden Faktoren ab:

  • NEG API-Trennlatenz: Die Trennungslatenz der NEG API stellt die aktuelle Zeit dar, die für den Abschluss des Trennvorgangs in Google Cloud benötigt wurde. Dies wird durch verschiedene Faktoren außerhalb von Kubernetes beeinflusst, einschließlich des Typs des Load-Balancers und der jeweiligen Zone.

  • Drain-Latenz: Die Drain-Latenz stellt die Zeit dar, die für das Load-Balancing benötigt wird, um anzufangen, Traffic von einem bestimmten Teil Ihres Systems wegzuleiten. Nachdem der Drain-Vorgang initiiert wurde, sendet der Load-Balancer keine neuen Anfragen mehr an den Endpunkt. Es gibt jedoch immer noch eine Latenz beim Auslösen des Drain-Vorgangs (Drain-Latenz), was zu einem vorübergehenden 503-Fehler führen kann, wenn der Pod nicht mehr vorhanden ist. eine

  • Konfiguration der Systemdiagnose: Schwellenwerte für sensible Systemdiagnosen reduzieren die Dauer von 503-Fehlern, da sie dem Load-Balancer signalisieren können, keine Anfragen mehr an Endpunkte zu senden, auch wenn der Trennvorgang nicht abgeschlossen ist.

  • Kulanzzeitraum für die Beendigung: Der Kulanzzeitraum für die Beendigung bestimmt die maximale Zeit, die einem Pod zum Beenden gewährt wird. Ein Pod kann jedoch beendet werden, bevor der Kulanzzeitraum für die Beendigung abgeschlossen ist. Wenn ein Pod länger als dieser Zeitraum dauert, wird der Pod zum Beenden am Ende dieses Zeitraums gezwungen. Dies ist eine Einstellung für den Pod und muss in der Arbeitslastdefinition konfiguriert werden.

Mögliche Lösung:

Wenden Sie die folgenden Einstellungen an, um diese 5XX-Fehler zu vermeiden. Die Zeitüberschreitungswerte sind Vorschläge und Sie müssen sie möglicherweise für Ihre spezifische Anwendung anpassen. Der folgende Abschnitt führt Sie durch den Anpassungsprozess.

Die folgende Abbildung zeigt, wie der Pod mit preStopHook aktiv bleibt:

Zeitlimit für Back-End-Drain ist festgelegt

Führen Sie die folgenden Schritte aus, um Fehler der 500er-Serie zu vermeiden:

  1. Legen Sie BackendService Drain Timeout für Ihren Dienst auf 1 Minute fest.

  2. Erweitern Sie terminationGracePeriod auf dem Pod.

    Legen Sie terminationGracePeriodSeconds auf dem Pod auf 3,5 Minuten fest. In Kombination mit den empfohlenen Einstellungen hat Ihr Pod 30 bis 45 Sekunden Zeit für ein ordnungsgemäßes Herunterfahren, nachdem der Endpunkt des Pods aus der NEG entfernt wurde. Wenn Sie mehr Zeit für das ordnungsgemäße Herunterfahren benötigen, können Sie den Kulanzzeitraum verlängern oder der Anleitung im Abschnitt Zeitüberschreitungen anpassen folgen.

    Das folgende BackendConfig-Manifest gibt ein Zeitlimit für den Verbindungsausgleich von 210 Sekunden (3,5 Minuten) an:

    apiVersion: v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  terminationGracePeriodSeconds: 210
  containers:
  - name: my-app
    image: my-app-image:latest
    ports:
    - containerPort: 80

  3. Wenden Sie ein preStopHook auf alle Container an.

    Wenden Sie eine preStopHook an, die dafür sorgt, dass der Pod 120 Sekunden länger aktiv ist, während der Endpunkt des Pods im Load-Balancer per Drain beendet wird und der Endpunkt aus der NEG entfernt wird.

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    # Container configuration details...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 120s"]

Zeitlimits anpassen

Zur Gewährleistung der Pod-Kontinuität und zur Vermeidung von 500-Fehlern muss der Pod aktiv sein, bis der Endpunkt aus der NEG entfernt wird. Insbesondere zur Vermeidung von 502- und 503-Fehlern sollten Sie eine Kombination aus Zeitüberschreitungen und einem preStopHook implementieren.

Fügen Sie dem Pod einen preStopHook hinzu, um den Pod während des Herunterfahrens länger aktiv zu lassen. Führen Sie den preStopHook aus, bevor einem Pod das Beenden signalisiert wird. Damit kann preStopHook den Pod so lange behalten, bis der entsprechende Endpunkt aus der NEG entfernt wird.

Um die Dauer zu verlängern, die ein Pod während des Herunterfahrens aktiv bleibt, fügen Sie einen preStopHook in die Pod-Konfiguration ein:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStopHook:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Sie können Zeitlimits und zugehörige Einstellungen konfigurieren, um das ordnungsgemäße Herunterfahren von Pods während des Herunterskalierens von Arbeitslasten zu verwalten. Sie können Zeitlimits anhand bestimmter Anwendungsfälle anpassen. Wir empfehlen, mit längeren Zeitüberschreitungen zu beginnen und die Dauer nach Bedarf zu reduzieren. Sie können die Zeitlimits anpassen, indem Sie Zeitparameter und die preStopHook auf folgende Weise konfigurieren:

Zeitlimit für Back-End-Dienst-Drain

Der Parameter Backend Service Drain Timeout ist standardmäßig nicht festgelegt und hat keine Auswirkungen. Wenn Sie den Parameter Backend Service Drain Timeout festlegen und aktivieren, beendet der Load-Balancer die Weiterleitung neuer Anfragen an den Endpunkt und wartet das Zeitlimit, bevor vorhandene Verbindungen beendet werden.

Sie können den Parameter Backend Service Drain Timeout mit BackendConfig mit Ingress, mit GCPBackendPolicy mit Gateway oder manuell auf dem BackendService mit eigenständigen NEGs festlegen. eine Das Zeitlimit sollte 1,5- bis 2-mal länger sein als die Zeit für die Verarbeitung einer Anfrage. Dadurch wird sichergestellt, dass eine Anfrage, die kurz vor dem Drain eingegangen ist, abgeschlossen wird, bevor die Zeitüberschreitung beendet ist. Wenn Sie den Parameter Backend Service Drain Timeout auf einen Wert größer als 0 setzen, werden 503-Fehler minimiert, da keine neuen Anfragen an Endpunkte gesendet werden, die zum Entfernen vorgemerkt sind. Damit dieses Zeitlimit wirksam ist, müssen Sie es in Verbindung mit preStopHook verwenden. So bleibt der Pod während des Drains aktiv. Ohne diese Kombination erhalten vorhandene Anfragen, die nicht abgeschlossen wurden, den Fehler 502.

Zeit preStopHook

preStopHook muss das Herunterfahren des Pods so lange verzögern, bis sowohl die Drain-Latenz als auch die Zeitüberschreitung für den Drain des Back-End-Dienstes abgeschlossen sind, sodass ein ordnungsgemäßer Verbindungsausgleich und die Entfernung des Endpunkts vom NEG gewährleistet sind, bevor der Pod heruntergefahren wird.

Achten Sie für optimale Ergebnisse darauf, dass die Ausführungszeit von preStopHook kleiner oder gleich der Summe von Backend Service Drain Timeout und der Drain-Latenz ist.

Der Wert kann so berechnet werden:

preStopHook >= Backend Service Drain Timeout + Drain Latency

Wir empfehlen, die Drain-Latenz auf 1 Minute festzulegen. Wenn 500-Fehler bestehen bleiben, schätzen Sie die Gesamtdauer des Vorkommens und fügen Sie der Latenz das Doppelte davon hinzu. Dadurch wird sichergestellt, dass der Pod ausreichend Zeit zum ordnungsgemäßen Drain hat, bevor er aus dem Dienst entfernt wird. Sie können diesen Wert anpassen, wenn er für Ihren spezifischen Anwendungsfall zu lang ist.

Alternativ können Sie den Zeitpunkt schätzen, indem Sie den Löschzeitstempel vom Pod und den Zeitstempel für die Entfernung des Endpunkts aus der NEG in den Cloud-Audit-Logs untersuchen.

Parameter für den Kulanzzeitraum für die Beendigung

Sie müssen den Parameter terminationGracePeriod so konfigurieren, dass ausreichend Zeit für den Abschluss des preStopHook und für das ordnungsgemäße Herunterfahren des Pods bleibt.

Wenn nicht explizit festgelegt, beträgt der terminationGracePeriod standardmäßig 30 Sekunden. Sie können den optimalen terminationGracePeriod mit der folgenden Formel berechnen:

terminationGracePeriod >= preStopHook Time + Pod shutdown time

So definieren Sie terminationGracePeriod in der Pod-Konfiguration so:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

NEG beim Erstellen einer internen Ingress-Ressource nicht gefunden

Der folgende Fehler kann auftreten, wenn Sie ein internes Ingress in GKE erstellen:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Dieser Fehler tritt auf, weil Ingress für interne Anwendungs-Load-Balancer Netzwerk-Endpunktgruppen (NEGs) als Back-Ends erfordert.

Fügen Sie in freigegebenen VPC-Umgebungen oder -Clustern mit aktivierten Netzwerkrichtlinien dem Dienstmanifest die Annotation cloud.google.com/neg: '{"ingress": true}' hinzu.

504 Gateway-Zeitüberschreitung: Upstream-Zeitüberschreitung bei Anfrage

Der folgende Fehler kann auftreten, wenn Sie über einen internen Ingress in GKE auf einen Dienst zugreifen:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Dieser Fehler tritt auf, weil Traffic, der an interne Anwendungs-Load-Balancer gesendet wird, von Envoy-Proxys im Nur-Proxy-Subnetzbereich weitergeleitet wird.

Erstellen Sie eine Firewallregel im targetPort des Dienstes, um Traffic aus dem Nur-Proxy-Subnetzbereich zuzulassen.

Fehler 400: Ungültiger Wert für das Feld "resource.target"

Der folgende Fehler kann auftreten, wenn Sie über einen internen Ingress in GKE auf einen Dienst zugreifen:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Stellen Sie ein Nur-Proxy-Subnetz bereit, um dieses Problem zu beheben.

Fehler während der Synchronisierung: Fehler beim Ausführen der Synchronisierungsroutine des Load-Balancers: Load-Balancer existiert nicht

Einer der folgenden Fehler kann auftreten, wenn die GKE-Steuerungsebene aktualisiert wird oder Sie ein Ingress-Objekt ändern:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

oder:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Um diese Probleme zu beheben, führen Sie die folgenden Schritte aus:

  • Fügen Sie das Feld hosts im Abschnitt tls des Ingress-Manifests hinzu und löschen Sie dann das Ingress-Objekt. Warten Sie fünf Minuten, bis GKE die nicht verwendeten Ingress-Ressourcen gelöscht hat. Erstellen Sie dann das Ingress neu. Weitere Informationen finden Sie unter Feld „Hosts“ eines Ingress-Objekts.
  • Setzen Sie die Änderungen zurück, die Sie am Ingress-Objekt vorgenommen haben. Fügen Sie dann ein Zertifikat mit einer Annotation oder einem Kubernetes-Secret hinzu.

Bekannte Probleme

HTTPS-Weiterleitungen können nicht mit dem V1-Ingress-Namensschema aktiviert werden

Sie können HTTPS-Weiterleitungen für GKE-Ingress-Ressourcen, die in GKE-Version 1.16.8-gke.12 und früher erstellt wurden, nicht aktivieren. Sie müssen das Ingress neu erstellen, bevor Sie HTTPS-Weiterleitungen aktivieren können. Andernfalls wird ein Fehlerereignis erstellt und das Ingress wird nicht synchronisiert.

Die Fehlermeldung sieht in etwa so aus:

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

Google Cloud Armor-Sicherheitsrichtlinienfelder wurden aus BackendConfig entfernt

Es gibt ein bekanntes Problem, bei dem beim Aktualisieren einer BackendConfig-Ressource mithilfe der v1beta1 API eine aktive Google Cloud Armor-Sicherheitsrichtlinie aus ihrem Service entfernt wird. Dieses Problem betrifft die folgenden GKE-Versionen:

  • 1.18.19-gke.1400 bis 1.18.20-gke.5099
  • 1.19.10-gke.700 bis 1.19.14-gke.299
  • 1.20.6-gke.700 bis 1.20.9-gke.899

Wenn Sie Google Cloud Armor für Ihre Ingress-Ressourcen nicht über die BackendConfig konfigurieren, sind Ihre Cluster nicht von diesem Problem betroffen.

Für GKE-Cluster, die Google Cloud Armor über die BackendConfig konfigurieren, wird dringend empfohlen, nur BackendConfig-Ressourcen mit der v1 API zu aktualisieren. Wenn Sie eine BackendConfig mit v1beta1-BackendConfig-Ressourcen auf Ihren Cluster anwenden, wird die Google Cloud Armor-Sicherheitsrichtlinie aus dem Service entfernt, auf den sie verweist.

Aktualisieren Sie Ihre BackendConfig nur mit der v1 BackendConfig API, um dieses Problem zu beheben. Die v1-BackendConfig unterstützt dieselben Felder wie v1beta1 und nimmt keine funktionsgefährdenden Änderungen vor, sodass das API-Feld transparent aktualisiert werden kann. Ersetzen Sie das Feld apiVersion aller aktiven BackendConfig-Manifeste durch cloud.google.com/v1 und verwenden Sie nicht cloud.google.com/v1beta1. Das folgende Beispielmanifest beschreibt eine BackendConfig-Ressource, die die v1 API verwendet:

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

Wenn Sie CI/CD-Systeme oder -Tools haben, die BackendConfig-Ressourcen regelmäßig aktualisieren, achten Sie darauf, dass Sie in diesen Systemen die cloud.google.com/v1-API-Gruppe verwenden.

Wenn Ihre BackendConfig bereits mit der v1beta1 API aktualisiert wurde, wurde Ihre Google Cloud Armor-Sicherheitsrichtlinie möglicherweise entfernt. Mit dem folgenden Befehl können Sie feststellen, ob dies der Fall ist:

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

Wenn die Antwort eine Ausgabe zurückgibt, ist Ihr Cluster von diesem Problem betroffen. Die Ausgabe dieses Befehls gibt eine Liste der BackendConfig-Ressourcen (<namespace>/<name>) zurück, die vom Problem betroffen sind. Ist die Ausgabe leer, wurde Ihre BackendConfig seit dem Auftreten des Problems nicht mit der v1beta1 API aktualisiert. Alle zukünftigen Updates Ihrer BackendConfig sollten nur v1 verwenden.

Wenn Ihre Google Cloud Armor-Sicherheitsrichtlinie entfernt wurde, können Sie mit der folgenden Logging-Abfrage feststellen, wann sie entfernt wurde:

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

Wenn einer Ihrer Cluster betroffen ist, kann dies durch Aktualisieren der BackendConfig-Ressource mithilfe der v1 API korrigiert werden.

Führen Sie ein Upgrade Ihrer GKE-Steuerungsebene auf eine der folgenden aktualisierten Versionen durch, in denen dieses Problem behoben wurde und die sichere Verwendung von v1beta1-BackendConfig-Ressourcen möglich ist.

  • 1.18.20-gke.5100 und höher
  • 1.19.14-gke.300 und höher
  • 1.20.9-gke.900 und höher

Nächste Schritte