Ingress-Features konfigurieren

Diese Seite bietet eine umfassende Übersicht über die in Google Cloud unterstützten und konfigurierbaren Einstellungen von Kubernetes Ingress. Ingress für Google Kubernetes Engine (GKE) und Anthos bietet Load-Balancing für Unternehmen mit enger Integration in Ihr Google Cloud VPC-Netzwerk.

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 Cluster-gehosteter Ingress-Controller Von Google gehosteter 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
Versionsunterstützung Alle GKE 1.16.5+ GKE 1.14 und höher
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
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

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 Anthos-Versionen unterstützt.

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

Ingress-Features konfigurieren

Wenn Sie einen Ingress mit dem Standardcontroller erstellen, können Sie den Typ des Load-Balancers (einen externen HTTP(S)-Load-Balancer oder einen internen HTTP(S)-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 und BackendConfigs 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

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.

Multi-Cluster-Ingress

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

Ein Service oder MultiClusterService kann die Annotation cloud.google.com/backend-config oder beta.cloud.google.com/backend-config verwenden, um den Namen einer BackendConfig anzugeben. In Verbindung mit einem Service oder MultiClusterService fordert die BackendConfig-Ressource Google Cloud auf, die Einstellungen für den Back-End-Dienst zu erstellen oder zu ändern.

In den folgenden Beispielen:

Wenn Sie die GKE-Version 1.16-gke.3 oder höher verwenden, sollten Sie die Annotation cloud.google.com/backend-config verwenden, auch wenn die Annotation beta.cloud.google.com/backend-config funktioniert. Bei älteren Versionen müssen Sie die Annotation beta.cloud.google.com/backend-config verwenden.

Gleiche BackendConfig für alle Service-Ports

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

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Alle unterstützten Versionen

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Eindeutige BackendConfig pro Service-Port

Sie können eine benutzerdefinierte BackendConfig für bestimmte Ports eines Service oder MultiClusterService angeben, indem Sie einen Schlüssel verwenden, der mit dem Namen oder Portnummer des Ports übereinstimmt. Der Ingress-Controller verwendet die spezifische BackendConfig, wenn er einen Load-Balancer-Back-End-Dienst für einen referenzierten Service-Port erstellt.

1.16-gke.3+

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

In GKE kann die BackendConfig-Annotation eines Service entweder auf den Namen des Ports (spec.ports[].name) oder die Nummer des Ports (spec.ports[].port) verweisen. Im obigen Beispiel können Sie SERVICE_REFERENCE_A durch PORT_NUMBER_1 oder PORT_NAME_1 und SERVICE_REFERENCE_B durch PORT_NUMBER_2 oder PORT_NAME_2 ersetzen.

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

Zeitlimit für 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

Dabei gilt:

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

Dabei gilt:

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

Google Cloud Armor-Sicherheitsrichtlinie

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"

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

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

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}"

Ü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

Eine vollständige Liste der Features, die Sie mit einer BackendConfig festlegen können, finden Sie in der Feature-Tabelle im Abschnitt "BackendConfig".

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 ein HTTP(S)-Load-Balancing und einen zugehörigen Back-End-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" stellt Informationen zum Back-End-Dienst bereit, der dem Kubernetes-Dienst my-service zugeordnet ist.
    • 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" stellt Informationen zum Back-End-Dienst bereit, der dem Standard-Back-End (404-Server) zugeordnet ist.
    • 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

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. Diese kann auftreten, wenn Sie die BackendConfig-Ressource gar nicht oder im falschen Namespace erstellt haben oder den Verweis in der Dienstannotation falsch geschrieben haben.

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

kubectl get event

Der folgende Ausgabetyp gibt 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

Sicherheitsrichtlinie wurde 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 nicht vorhandene Richtlinie angibt, wird regelmäßig ein Warnungsereignis ausgegeben. Stellen Sie zur Problembehebung sicher, dass Sie in der BackendConfig-Ressource die richtige Sicherheitsrichtlinie namentlich angeben.

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

kubectl get event

Der folgende Ausgabetyp gibt 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.

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 to GCP: 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