Gateway-Ressourcen mithilfe von Richtlinien konfigurieren

Auf dieser Seite erfahren Sie, wie Sie den Load-Balancer konfigurieren, den Google Kubernetes Engine (GKE) erstellt, wenn Sie ein Gateway in einem GKE-Cluster bereitstellen.

Wenn Sie ein Gateway bereitstellen, bestimmt die GatewayClass-Konfiguration, welcher Load-Balancer von GKE erstellt wird. Dieser verwaltete Load-Balancer ist mit Standardeinstellungen vorkonfiguriert, die Sie mithilfe einer Richtlinie ändern können.

Sie können Gateway-Ressourcen an Ihre Infrastruktur- oder Anwendungsanforderungen anpassen. Hängen Sie dazu Richtlinien an Gateways, Services oder ServiceImports an. Nachdem Sie eine Richtlinie angewendet oder geändert haben, müssen Sie Ihre Gateway-, Routen- oder Service-Ressourcen nicht löschen oder neu erstellen. Die Richtlinie wird vom Gateway-Controller verarbeitet und die zugrunde liegende Load-Balancer-Ressource wird entsprechend der (neuen) Richtlinie (neu) konfiguriert.

Vorbereitung

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Anforderungen für GKE Gateway Controller

  • Für Standard, GKE-Version 1.24 oder höher
  • Für Autopilot, GKE-Version 1.26 oder höher.
  • Google Cloud CLI-Version 407.0.0 oder höher.
  • Die Gateway API wird nur in VPC-nativen Clustern unterstützt.
  • Wenn Sie die internen GatewayClasses verwenden, müssen Sie ein Nur-Proxy-Subnetz aktivieren.
  • Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein.
  • Wenn Sie Istio verwenden, müssen Sie Istio auf eine der folgenden Versionen aktualisieren:
    • 1.15.2 oder höher
    • 1.14.5 oder höher
    • 1.13.9 oder höher
  • Wenn Sie eine freigegebene VPC verwenden, müssen Sie dem GKE-Dienstkonto für das Dienstprojekt im Hostprojekt die Rolle Compute Network User zuweisen.

Limits und Einschränkungen

Zusätzlich zu den Limits und Einschränkungen für GKE Gateway Controller gelten die folgenden Einschränkungen speziell für Richtlinien, die auf die Gateway-Ressourcen angewendet werden:

  • Die GCPGatewayPolicy-Ressourcen können nur an ein gateway.networking.k8s.io Gateway angehängt werden.

  • Die GCPGatewayPolicy-Ressourcen müssen im selben Namespace wie das Ziel Gateway vorhanden sein.

  • Wenn Sie ein einzelnes Cluster-Gateway verwenden, müssen die Ressourcen GCPBackendPolicy und HealthCheckPolicy auf eine Service-Ressource verweisen.

  • Wenn Sie ein Multi-Cluster-Gateway verwenden, müssen sich die Ressourcen GCPBackendPolicy und HealthCheckPolicy auf eine ServiceImport-Ressource beziehen.

  • Es kann immer nur ein GCPGatewayPolicy an einen Dienst angehängt werden. Wenn zwei GCPGatewayPolicy-Richtlinien erstellt wurden und auf denselben Service oder ServiceImport ausgerichtet sind, hat die ältere Richtlinie Vorrang und die zweite wird nicht angehängt.

  • Hierarchische Richtlinien werden von GKE Gateway nicht unterstützt.

  • Die Ressourcen HealthCheckPolicy und GCPBackendPolicy müssen sich im selben Namespace befinden wie die Ressource Service oder ServiceImport des Ziels.

  • Die Ressourcen GCPBackendPolicy und HealthCheckPolicy sind so strukturiert, dass sie nur auf einen einzigen Backend-Dienst verweisen können.

  • GCPBackendPolicy unterstützt keine HEADER_FIELD- oder HTTP_COOKIE-Optionen für die Sitzungsaffinität.

Globalen Zugriff für Ihr regionales internes Gateway konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Hängen Sie eine Richtlinie an die Gateway-Ressource an, um den globalen Zugriff mit Ihrem internen Gateway zu aktivieren.

Das folgende GCPGatewayPolicy-Manifest aktiviert das regionale interne Gateway für den globalen Zugriff:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

SSL-Richtlinien zum Sichern des Client-zu-Load-Balancer-Traffics konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Konfigurieren Sie die SSL-Richtlinie, um den Client-zu-Load-Balancer-Traffic zu sichern. Fügen Sie dazu den Namen Ihrer Richtlinie der GCPGatewayPolicy hinzu. Standardmäßig hat das Gateway keine SSL-Richtlinie definiert und ist nicht angehängt.

Achten Sie darauf, dass Sie eine SSL-Richtlinie erstellen, bevor Sie auf die Richtlinie in Ihrer GCPGatewayPolicy verweisen.

Das folgende GCPGatewayPolicy-Manifest gibt eine Sicherheitsrichtlinie mit dem Namen gke-gateway-ssl-policy an:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Systemdiagnosen konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Mit einer HealthCheckPolicy können Sie die Einstellungen für die Load-Balancer-Systemdiagnose steuern. Jeder Systemdiagnosetyp (http, https, grpc und http2) hat Parameter, die Sie festlegen können. Google Cloud erstellt für jeden Backend-Dienst und jeden GKE-Dienst eine eindeutige Systemdiagnose.

Damit Ihr Load Balancer normal funktioniert, müssen Sie möglicherweise einen benutzerdefinierten HealthCheckPolicy für Ihren Load Balancer konfigurieren, wenn der Pfad der Systemdiagnose nicht der Standardpfad „/“ ist. Diese Konfiguration ist auch erforderlich, wenn für den Pfad spezielle Header erforderlich sind oder Sie die Parameter der Systemdiagnose anpassen müssen. Beispiel: Wenn der Standardanfragepfad „/“ ist, auf Ihren Dienst aber nicht über diesen Anfragepfad zugegriffen werden kann und stattdessen „/health“ verwendet wird, um den Dienststatus zu melden, müssen Sie requestPath in Ihrer HealthCheckPolicy entsprechend konfigurieren.

Das folgende HealthCheckPolicy-Manifest zeigt alle verfügbaren Felder beim Konfigurieren einer Systemdiagnoserichtlinie:

Dienst

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Ersetzen Sie dabei Folgendes:

  • INTERVAL: Gibt das Prüfintervall in Sekunden für alle Systemdiagnose-Prober 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, beträgt der Google Cloud-Standardwert 15 Sekunden, wenn kein HealthCheckPolicy angegeben ist, und 5 Sekunden, wenn ein HealthCheckPolicy ohne checkIntervalSec-Wert angegeben ist. Weitere Informationen finden Sie unter Mehrere Prüfungen und Häufigkeit.
  • TIMEOUT ist die Zeitspanne, die Google Cloud bei einer Prüfung auf eine Antwort wartet. Der Wert von TIMEOUT muss kleiner oder gleich INTERVAL sein. Die Einheit sind Sekunden. Bei jeder Prüfung muss vor Ablauf des Zeitlimits ein HTTP 200-Antwortcode (OK) gesendet werden.
  • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD: Gibt die Anzahl der aufeinanderfolgenden Verbindungsversuche an, die für mindestens einen Prober erfolgreich sein oder fehlschlagen müssen, um den Systemzustand von fehlerfrei zu fehlerhaft oder von fehlerhaft zu fehlerfrei zu ändern. Wenn Sie einen dieser Parameter weglassen, lautet der Google Cloud-Standardwert 2.
  • PROTOCOL: Gibt ein Protokoll an, das von Prüfsystemen für Systemdiagnosen verwendet wird. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP, HTTPS und HTTP/2 und Erfolgskriterien für gRPC. Das ist ein erforderlicher Parameter.
  • ENABLED: gibt an, ob das Logging aktiviert oder deaktiviert ist.
  • PORT_SPECIFICATION: Gibt an, ob die Systemdiagnose einen festen (USE_FIXED_PORT), benannten Port (USE_NAMED_PORT) oder einen Bereitstellungsport (USE_SERVING_PORT) verwendet. Wenn keine Angabe erfolgt, folgt die Systemdiagnose dem in den Feldern port und portName angegebenen Verhalten. Wenn weder port noch portName angegeben sind, wird standardmäßig USE_SERVING_PORT verwendet.
  • PORT: Eine HealthCheckPolicy unterstützt nur die Angabe des Ports für die Load-Balancer-Systemdiagnose mithilfe einer Portnummer. Wenn Sie diesen Parameter weglassen, lautet der Google Cloud-Standardwert 80. Da der Load-Balancer Probes direkt an die IP-Adresse des Pods sendet, sollten Sie einen Port wählen, der zu einem containerPort eines Bereitstellungspods passt, selbst wenn der containerPort von einem targetPort des Dienstes referenziert wird. Sie sind nicht auf containerPorts beschränkt, auf den das targetPort eines Service verweist.
  • PORT_NAME: gibt den Portnamen an, wie in InstanceGroup.NamedPort.name definiert. Wenn sowohl port als auch portName definiert ist, berücksichtigt Google Cloud zuerst den Wert port.
  • HOST: Wert des Host-Headers in der Systemdiagnoseanfrage. Dieser Wert verwendet die RFC 1123-Definition eines Hostnamens, wobei aber numerische IP-Adressen nicht zulässig sind. Wenn dieser Wert nicht angegeben oder leer ist, wird standardmäßig die IP-Adresse der Systemdiagnose verwendet.
  • REQUEST_PATH: gibt den Anfragepfad der Systemdiagnoseanfrage an. Wenn nicht angegeben oder leer gelassen, wird standardmäßig / verwendet.
  • RESPONSE: gibt die Byte an, die mit dem Anfang der Antwortdaten abgeglichen werden sollen. Wenn nicht angegeben oder leer gelassen, interpretiert GKE jede Antwort als fehlerfrei. Die Antwortdaten können nur in ASCII-Format vorliegen.
  • PROXY_HEADER: gibt den Proxy-Header-Typ an. Sie können NONE oder PROXY_V1 verwenden. Die Standardeinstellung ist NONE.
  • GRPC_SERVICE_NAME ist ein optionaler Name des gRPC-Dienstes. Lassen Sie dieses Feld weg, um alle Services anzugeben.

Weitere Informationen zu HealthCheckPolicy-Feldern finden Sie in der healthChecks-Referenz.

Google Cloud Armor Backend-Sicherheitsrichtlinie zum Schutz Ihrer Backend-Dienste konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Konfigurieren Sie die Google Cloud Armor Backend-Sicherheitsrichtlinie. Fügen Sie dazu den Namen Ihrer Sicherheitsrichtlinie GCPBackendPolicy hinzu, um Ihre Backend-Dienste zu sichern. Standardmäßig hat das Gateway keine Google Cloud Armor Backend-Sicherheitsrichtlinie definiert und angehängt.

Sie müssen eine Google Cloud Armor Backend-Sicherheitsrichtlinie erstellen, bevor Sie auf die Richtlinie in Ihrer GCPBackendPolicy verweisen.

Das folgende GCPBackendPolicy-Manifest gibt eine Backend-Sicherheitsrichtlinie mit dem Namen example-security-policy an:

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

IAP konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Identity-Aware Proxy (IAP) erzwingt Zugriffssteuerungsrichtlinien für Back-End-Dienste, die einer HTTPRoute zugeordnet sind. Durch diese Erzwingung können nur authentifizierte Nutzer oder Anwendungen mit der richtigen IAM-Rolle (Identity and Access Management) auf diese Backend-Dienste zugreifen.

Standardmäßig ist kein IAP auf Ihre Backend-Dienste angewendet. Sie müssen IAP explizit in einem GCPBackendPolicy konfigurieren.

So konfigurieren Sie IAP mit Gateway:

  1. IAP für GKE aktivieren Konfigurieren Sie das Back-End nicht (BackendConfig konfigurieren), da BackendConfig nur im Fall eines Ingress-Deployments gültig ist.

  2. Erstellen Sie ein Secret für Ihren IAP:

    1. Wechseln Sie in der Google Cloud Console zur Seite Anmeldedaten:

      Zu den Anmeldedaten

    2. Klicken Sie auf den Namen des Clients und laden Sie die OAuth-Clientdatei herunter.

    3. Kopieren Sie das OAuth-Secret aus der OAuth-Clientdatei in die Zwischenablage.

    4. Erstellen Sie eine Datei mit dem Namen iap-secret.txt.

    5. Fügen Sie das OAuth-Secret mit dem folgenden Befehl in die iap-secret.txt-Datei ein:

      echo -n CLIENT_SECRET > iap-secret.txt
kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt

  3. So geben Sie eine IAP-Richtlinie an, die auf ein Secret verweist:

    1. Erstellen Sie das folgende GCPBackendPolicy-Manifest und ersetzen Sie SECRET_NAME bzw. CLIENT_ID. Speichern Sie das Manifest als backend-policy.yaml:

      Dienst

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: ""
    kind: Service
    name: lb-service

      Multi-Cluster-Dienst

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

    2. Wenden Sie das backend-policy.yaml-Manifest an:

      kubectl apply -f backend-policy.yaml

  4. Konfiguration überprüfen:

    1. Prüfen Sie, ob die Richtlinie nach dem Erstellen der GCPBackendPolicy mit IAP angewendet wurde:

      kubectl get gcpbackendpolicy

      Die Ausgabe sieht in etwa so aus:

      NAME             AGE
backend-policy   45m

    2. Verwenden Sie den „describe“-Befehl, um weitere Details zu erhalten:

      kubectl describe gcpbackendpolicy

      Die Ausgabe sieht in etwa so aus:

      Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPGatewayPolicy "default/backend-policy" was a success

Zeitlimit für Backend-Dienst konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Das folgende GCPBackendPolicy-Manifest gibt ein Zeitlimit für den Backend-Dienst von 40 Sekunden an. Das Feld timeoutSec ist standardmäßig auf 30 Sekunden eingestellt.

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Sitzungsaffinität konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Sie können die Sitzungsaffinität anhand der folgenden Kriterien konfigurieren:

  • IP-Adresse des Clients
  • Generiertes Cookie

Wenn Sie die Sitzungsaffinität für Ihren Service konfigurieren, wird die localityLbPolicy-Einstellung des Gateways auf MAGLEV festgelegt.

Wenn Sie eine Sitzungsaffinitätskonfiguration aus GCPBackendPolicy entfernen, setzt das Gateway die localityLbPolicy-Einstellung auf den Standardwert ROUND_ROBIN zurück.

Das folgende GCPBackendPolicy-Manifest gibt eine Sitzungsaffinität anhand der Client-IP-Adresse an:

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Das folgende GCPBackendPolicy-Manifest gibt eine Sitzungsaffinität anhand eines generierten Cookies an und legt die Cookie-TTL auf 50 Sekunden fest:

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Sie können die folgenden Werte für das Feld sessionAffinity.type verwenden:

  • CLIENT_IP
  • GENERATED_COOKIE
  • NONE

Zeitlimit für Verbindungsausgleich konfigurieren

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Sie können das Zeitlimit für den Verbindungsausgleich mit GCPBackendPolicy konfigurieren. Das Zeitlimit für den Verbindungsausgleich ist die Zeit in Sekunden, die gewartet wird, bis die Verbindung beendet wird. Das Zeitlimit kann zwischen 0 und 3.600 Sekunden liegen. Der Standardwert ist 0, wodurch auch der Verbindungsausgleich deaktiviert wird.

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

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Für die angegebene Dauer des Zeitlimits wartet GKE auf vorhandene Anfragen an das entfernte Backend, um den Vorgang abzuschließen. Der Load-Balancer sendet keine neuen Anfragen an das entfernte Backend. Nach dem Erreichen des Zeitlimits schließt GKE alle verbleibenden Verbindungen zum Backend.

HTTP-Zugriffs-Logging

In diesem Abschnitt wird eine Funktion beschrieben, die in GKE-Clustern mit Version 1.24 oder höher verfügbar ist.

Standard:

  • Der Gateway-Controller protokolliert alle HTTP-Anfragen von Clients in Cloud Logging.
  • Die Abtastrate beträgt 1.000.000. Das bedeutet, dass alle Anfragen protokolliert werden.

Sie können das Zugriffs-Logging auf Ihrem Gateway mithilfe eines GCPBackendPolicy auf drei Arten deaktivieren:

  • Sie können für GCPBackendPolicy den Abschnitt logging weglassen.
  • Sie können logging.enabled auf false setzen
  • Sie können logging.enabled auf true und logging.sampleRate auf 0 setzen.

Sie können auch die Abtastrate für das Zugriffs-Logging konfigurieren.

Mit dem folgenden GCPBackendPolicy-Manifest wird die Standardabtastrate für das Zugriffs-Logging geändert und auf 50% der HTTP-Anfragen für eine bestimmte Dienst-Ressource festgelegt:

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Multi-Cluster-Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Dieses Manifest hat die folgenden Felder:

  • enable: true: Aktiviert explizit das Zugriffs-Logging. Logs sind in Logging verfügbar.
  • sampleRate: 500000: gibt an, dass 50 % der Pakete protokolliert werden. Sie können einen Wert zwischen 0 und 1.000.000 verwenden. GKE konvertiert diesen Wert in einen Gleitkommawert im Bereich [0, 1]. Dazu wird der Wert durch 1.000.000 geteilt. 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. Wenn enable auf true gesetzt ist und sampleRate nicht angegeben ist, setzt GKE enable auf false.

Fehlerbehebung

Mehrere GCPBackendPolicy, die an denselben Service angehängt sind

Symptom:

Die folgende Statusbedingung kann auftreten, wenn Sie eine GCPBackendPolicy an eine Service oder ServiceImport anhängen:

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

Grund:

Diese Statusbedingung gibt an, dass Sie versuchen, eine zweite GCPBackendPolicy auf einen Service oder ServiceImport anzuwenden, an den bereits ein GCPBackendPolicy angehängt ist.

Mehrere GCPBackendPolicy, die an dieselbe Service oder ServiceImport angehängt sind, werden von GKE Gateway nicht unterstützt. Weitere Informationen finden Sie unter Einschränkungen.

Workaround:

Konfigurieren Sie eine einzelne GCPBackendPolicy, die alle benutzerdefinierten Konfigurationen enthält, und hängen Sie sie an Ihr Service oder ServiceImport an.

Nächste Schritte