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.

Featurevergleich

Die folgende Tabelle enthält eine Liste der in Google Cloud unterstützten Features für Ingress.

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
Dienstannotationen
Containernatives Load-Balancing (NEGs)
1.16.5.xB
1.17.13-gke.2600G
HTTPS vom Load-Balancer zu Back-Ends
HTTP/2
Ingress-Annotationen
Statische IP-Adressen
1.16.5.xB
1.17.13-gke.2600G
Auf Secrets beruhende Kubernetes-Zertifikate
1.16.5.xB
1.17.13-gke.2600G
Von Google verwaltete SSL-Zertifikate
1.16.5.xB
1.17.13-gke.2600G
Von Google verwaltete SSL-Zertifikate
1.17.9-gke.6300G
AlleB
FrontendConfig (Beta)
SSL-Richtlinie
1.16.15-gke.4901G
HTTP-zu-HTTPS-Weiterleitung
1.18.10-gke.600B
BackendConfig
Zeitlimit für Back-End-Dienst
1.16.5.xB
1.17.13-gke.2600G
Cloud CDN
Zeitlimit für Verbindungsausgleich
Benutzerdefinierte Konfiguration Load-Balancer-Systemdiagnosen
1.16.15-gke.4901G

1.16.5.xB
1.17.13-gke.2600G
Google Cloud Armor-Sicherheitsrichtlinie
Konfiguration des HTTP-Zugriffs-Loggings
1.16.10-gke.6G

1.16.5.xB
1.17.13-gke.2600G
Identity-Aware Proxy (IAP)
Sitzungsaffinität
1.16.5.xB
1.17.13-gke.2600G
Benutzerdefinierte Anfrageheader
1.15.3-gke.1G

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

Auf eine FrontendConfig-CRD wird durch eine Annotation für eine Ingress- oder MultiClusterIngress-Ressource verwiesen. Die FrontendConfig entspricht der gesamten Ingress-/MultiClusterIngress-Ressource, wie im folgenden Beispiel gezeigt:

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

BackendConfig mit Ihrem Ingress verknüpfen

Auf eine BackendConfig-CRD wird durch eine Annotation für eine Dienst- oder MultiClusterService-Ressource verwiesen. Der Dienst oder MultiClusterService verwendet die Annotation cloud.google.com/backend-config, um den Namen der BackendConfig anzugeben. In Verbindung mit einem Dienst oder MultiClusterService kann BackendConfig die Einstellungen für den Google Cloud-Back-End-Dienst bestimmen. Das folgende Beispiel zeigt, wie Sie eine BackendConfig an einen Dienst oder MultiClusterService anhängen. Der Schlüssel default bedeutet, dass alle Ports innerhalb des Dienstes der BackendConfig my-backendconfig zugeordnet sind, wenn diese Dienstports von einem Ingress referenziert werden:

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

Wenn Sie innerhalb desselben Dienstes für verschiedene Ports eindeutige BackendConfig-Einstellungen benötigen, können Sie diesen Ports bestimmte BackendConfig-Ressourcen explizit zuordnen. Der Schlüssel ports im folgenden Beispiel ermöglicht die explizite Verknüpfung von Ports:

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-name-1",
    "port-2":"backendconfig-name-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: service-port-1
    protocol: TCP
    targetPort: 50000
  - name: service-name-2
    port: service-port-2
    protocol: TCP
    targetPort: 8080
...

Alle unterstützten Versionen

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-name-1",
    "port-2":"backendconfig-name-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port:  service-port-1
    protocol: TCP
    targetPort: 50000
  - name: service-name-2
    port: >service-port-2
    protocol: TCP
    targetPort:8080
...

port-1 kann über die Nummer durch service-port-1 oder über den Namen durch service-name-1 auf Ports im Dienst verweisen (nur in GKE unterstützt). Jeder Port ist einem Back-End-Dienst des Google Cloud-Load-Balancers zugeordnet, über den Ports innerhalb des Dienstes unterschiedliche Konfigurationen haben können.

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 Funktionalität 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 FrontendConfig-CRD 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 Weiterleitung-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 unter HTTP-zu-HTTPS-Weiterleitung für externe HTTP(S)-Load-Balancer einrichten beschrieben und wie in dieses 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

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/v1beta1
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/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

Dabei gilt:

  • cdnEnabled: Wenn dieser Wert auf true gesetzt ist, wird Cloud CDN für dieses Ingress-Back-End aktiviert.
  • includeHost: Wenn dieser Wert auf true gesetzt ist, werden Anfragen an verschiedene Hosts getrennt im Cache gespeichert.
  • includeProtocol: Wenn dieser Wert auf true gesetzt ist, werden HTTP- und HTTPS-Anfragen getrennt im Cache gespeichert.
  • includeQueryString: 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.
  • queryStringBlacklist: 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.
  • queryStringWhitelist: 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.

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

Eine Methode besteht darin, Systemdiagnosen explizit über eine BackendConfig zu konfigurieren. Wenn diese Parameter festgelegt sind, haben sie Vorrang vor den Einstellungen der Kubernetes-Bereitschaftsprüfung und den Standardwerten der Systemdiagnose.

Sie können mehrere GKE-Dienste so konfigurieren, dass sie auf dieselbe BackendConfig als wiederverwendbare Vorlage verweisen. Für healthCheck-Parameter 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: Gibt den Port mithilfe einer Portnummer an. Wenn Sie diesen Parameter weglassen, verwendet Google Cloud den Standardwert 80. Wenn Sie den containernatives Load-Balancing verwenden, stellen Prüfsysteme eine Verbindung zur IP-Adresse eines bereitstellenden Pods her. Andernfalls stellen Systemdiagnoseprüfungen eine Verbindung zur IP-Adresse des Knotens her, auf dem der Bereitstellungs-Pod ausgeführt wird.

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.

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/v1beta1
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/v1beta1
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/v1beta1
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: gcr.io/google-samples/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/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-service
          servicePort: 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.

Nächste Schritte