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, wird sie vom Gateway-Controller verarbeitet und die zugrunde liegende Load-Balancer-Ressource wird automatisch neu konfiguriert. Auf diese Weise müssen Sie Ihre Gateway-, Routen- oder Dienst-Ressourcen nicht löschen oder neu erstellen.

Sie können auch eine BackendTLSPolicy verwenden, um Einstellungen für die Backend-Authentifizierung mit TLS zu konfigurieren, um die Identität der Backends zu überprüfen, mit denen das Gateway eine Verbindung herstellt. Weitere Informationen finden Sie unter Backend-TLS konfigurieren.

Hinweis

Führen Sie die folgenden Aufgaben aus, 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  • Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Anforderungen für GKE Gateway Controller

  • Die Gateway API wird nur in VPC-nativen Clustern unterstützt.
  • Wenn Sie die regionalen oder regionsübergreifenden 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 Einschränkungen und Limits für den GKE Gateway Controller gelten die folgenden Einschränkungen speziell für Richtlinien, die auf die Gateway-Ressourcen angewendet werden:

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

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

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

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

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

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

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

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

  • GCPBackendPolicy unterstützt die Optionen HEADER_FIELD oder HTTP_COOKIE für die Sitzungsaffinität nicht. Verwenden Sie für die Sitzungsaffinität HEADER_FIELD oder HTTP_COOKIE die Ressource „GCPTrafficDistributionPolicy“.

  • Verwenden Sie nicht denselben Backend-Dienst für Gateways mit unterschiedlichen GatewayClass-Typen (z. B. global im Vergleich zu regional, intern im Vergleich zu extern oder verwaltet im Vergleich zu klassisch), wenn für diese Gateways inkompatible Konfigurationen erforderlich sind. Beispiel: Eine GCPBackendPolicy, die mit Funktionen konfiguriert wurde, die von einer „Classic“-GatewayClass nicht unterstützt werden, kann nicht auf einen Dienst angewendet werden, der auch von einem „Classic“-Gateway verwendet wird. Um eine korrekte Konfiguration zu gewährleisten, erstellen Sie für jedes Gateway, das unterschiedliche Richtlinieneinstellungen erfordert, einen separaten Dienst.

  • Die mit einer GCPTrafficDistributionPolicy konfigurierte Sitzungsaffinität wird nur für Single-Cluster-Gateways unterstützt.

  • Die Sitzungsaffinität von GCPTrafficDistributionPolicy ist nicht mit InferencePool-Ressourcen kompatibel, da diese spezielle Load-Balancing-Algorithmen für die Lokalität verwenden.

  • Mit GCPTrafficDistributionPolicy kann keine Sitzungsaffinität oder Ort-Load-Balancing-Richtlinie für den klassischen Application Load Balancer konfiguriert werden.

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

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

  • Es kann jeweils nur eine GCPBackendPolicy an eine einzelne Zielressource (Service, ServiceImport, InferencePool oder GCPInferencePoolImport) angehängt werden. Wenn mehrere GCPBackendPolicy-Ressourcen erstellt werden, die auf dieselbe Ressource ausgerichtet sind, hat die älteste Richtlinie Vorrang und die neuere wird nicht angehängt.

  • Die Ressourcen HealthCheckPolicy und GCPBackendPolicy müssen sich im selben Namespace wie die Zielressource Service, ServiceImport, InferencePool oder GCPInferencePoolImport befinden.

  • GCPBackendPolicy- und HealthCheckPolicy-Ressourcen können nur auf eine einzelne Ressource (z. B. einen Dienst oder InferencePool) ausgerichtet sein.

Best Practice:Erstellen Sie für jedes Gateway einen separaten Dienst mit einer anderen GatewayClass, um die Kompatibilität zwischen den Richtlinien des Dienstes und dem Load-Balancer-Typ zu gewährleisten.

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:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Region für Ihr Multi-Cluster-Gateway konfigurieren

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

Wenn Ihre Flotte Cluster in mehreren Regionen hat, müssen Sie möglicherweise regionale Gateways in verschiedenen Regionen für verschiedene Anwendungsfälle bereitstellen, z. B. für regionenübergreifende Redundanz, geringe Latenz und Datenhoheit. Im Konfigurationscluster Ihres Multi-Cluster-Gateways können Sie die Region angeben, in der Sie die regionalen Gateways bereitstellen möchten. Wenn Sie keine Region angeben, ist die Standardregion die Region des Konfigurationsclusters.

Verwenden Sie das Feld region in der GCPGatewayPolicy, um eine Region für Ihr Multi-Cluster-Gateway zu konfigurieren. Im folgenden Beispiel ist das Gateway in der Region us-central1 konfiguriert:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-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 der 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 in der GCPGatewayPolicy-Ressource auf die Richtlinie 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.

Standardmäßig ist für Back-End-Dienste, die die Anwendungsprotokolle HTTP oder kubernetes.io/h2c verwenden, die Systemdiagnose vom Typ HTTP. Für das HTTPS-Protokoll ist die Standard-Systemdiagnose vom Typ HTTPS. Für das HTTP2-Protokoll ist die Standard-Systemdiagnose vom Typ HTTP2.

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

Damit Ihr Load Balancer normal funktioniert, müssen Sie möglicherweise eine benutzerdefinierte 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

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  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:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-Cluster-InferencePool

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: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Ersetzen Sie Folgendes:

  • INTERVAL: Gibt das Prüfintervall in Sekunden für jeden 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 Standardwert Google Cloud 15 Sekunden, wenn keine HealthCheckPolicy angegeben ist, und 5 Sekunden, wenn eine HealthCheckPolicy ohnecheckIntervalSec-Wert angegeben ist. Weitere Informationen finden Sie unter Mehrere Prüfungen und Häufigkeit.
  • TIMEOUT: Gibt die Zeitspanne an, dieGoogle 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, ist der Standardwert für Google Cloud 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, Erfolgskriterien für gRPC und Erfolgskriterien für TCP. Das ist ein erforderlicher Parameter.
  • ENABLED: Gibt an, ob das Logging aktiviert oder deaktiviert ist.
  • PORT_SPECIFICATION: Gibt an, ob für die Systemdiagnose ein fester Port (USE_FIXED_PORT), ein benannter Port (USE_NAMED_PORT) oder ein Serving-Port (USE_SERVING_PORT) verwendet wird. Wenn nicht angegeben, folgt die Systemdiagnose dem Verhalten, das im Feld port angegeben ist. Wenn port nicht angegeben ist, 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 die in der targetPort eines Dienstes verwiesen wird.
  • 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: Gibt die Anwendungsdaten an, die nach dem Herstellen der TCP-Verbindung gesendet werden sollen. Wenn nichts angegeben ist, ist der Standardwert leer. Wenn sowohl die Anfrage als auch die Antwort leer sind, weist bereits der erfolgreiche Verbindungsaufbau auf ein fehlerfreies System hin. Die Anfragedaten dürfen nur im ASCII-Format vorliegen.
  • 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 dürfen nur ASCII-Zeichen enthalten.
  • PROXY_HEADER: Gibt den Proxy-Headertyp 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.

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 Cloud Armor Backend-Sicherheitsrichtlinie. Fügen Sie dazu den Namen Ihrer Sicherheitsrichtlinie zu GCPBackendPolicy hinzu, um Ihre Backend-Dienste zu sichern. Standardmäßig hat das Gateway keine Cloud Armor-Backend-Sicherheitsrichtlinie definiert und angehängt.

Sie müssen eine Cloud Armor-Backend-Sicherheitsrichtlinie erstellen, bevor Sie in Ihrer GCPBackendPolicy auf die Richtlinie verweisen. Wenn Sie ein regionales Gateway aktivieren, müssen Sie eine regionale Cloud Armor-Back-End-Sicherheitsrichtlinie erstellen.

Das folgende GCPBackendPolicy-Manifest gibt eine Back-End-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:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  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:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-Cluster-InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

IAP konfigurieren

Identity-Aware Proxy (IAP) erzwingt Zugriffssteuerungsrichtlinien für Backend-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 einer GCPBackendPolicy konfigurieren.

So konfigurieren Sie IAP mit Gateway:

  1. Rufen Sie die Client-ID und den Clientschlüssel für Ihren OAuth-Client ab. Der Clientschlüssel ist nur verfügbar, wenn Sie Ihren OAuth-Client erstellen. Weitere Informationen finden Sie unter OAuth-Clients verwalten.

  2. IAP für GKE aktivieren

    Sie müssen keine BackendConfig erstellen, da BackendConfig eine Ingress-Konfigurationsressource ist.

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

    1. Speichern Sie das folgende GCPBackendPolicy-Manifest als backend-policy.yaml:

      Dienst

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: SERVICE_NAME

      Ersetzen Sie Folgendes:

      • CLIENT_SECRET: der OAuth-Clientschlüssel.
      • CLIENT_ID: Die OAuth-Client-ID.
      • SERVICE_NAME: der Name des Dienstes, auf den in der GCPBackendPolicy verwiesen wird.

      Multi-Cluster-Dienst

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: SERVICEIMPORT_NAME

      Ersetzen Sie Folgendes:

      • CLIENT_SECRET: der OAuth-Clientschlüssel.
      • CLIENT_ID: Die OAuth-Client-ID.
      • SERVICEIMPORT_NAME: Der Name des ServiceImport, der in der GCPBackendPolicy als Ziel verwendet werden soll.

    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 angewendet wurde, nachdem Sie Ihre GCPBackendPolicy mit IAP erstellt haben:

      kubectl get gcpbackendpolicy

      Die Ausgabe sieht 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 GCPBackendPolicy "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:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  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
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-Cluster-InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Backend-Auswahl mit GCPBackendPolicy konfigurieren

Mit dem CUSTOM_METRICS-Balancing-Modus in der GCPBackendPolicy können Sie bestimmte benutzerdefinierte Messwerte konfigurieren, die beeinflussen, wie Backend-Dienste von Load Balancern Traffic verteilen. In diesem Load-Balancing-Modus wird das Load-Balancing anhand benutzerdefinierter Messwerte durchgeführt, die Sie definieren und die von den Anwendungs-Back-Ends gemeldet werden.

Weitere Informationen finden Sie unter Trafficverwaltung mit benutzerdefinierten Messwerten für das Load-Balancing.

Das Array customMetrics[] im Feld backends[] enthält die folgenden Felder:

  • name: Gibt den benutzerdefinierten Namen des benutzerdefinierten Messwerts an.
  • maxUtilization: Legt die Ziel- oder maximale Auslastung für diesen Messwert fest. Der gültige Bereich ist [0, 100].
  • dryRun: ein boolesches Feld. Wenn „true“, werden die Messwertdaten an Cloud Monitoring gemeldet, haben aber keinen Einfluss auf Load-Balancing-Entscheidungen.

Beispiel

Das folgende Beispiel zeigt ein GCPBackendPolicy-Manifest, das benutzerdefinierte Messwerte für die Back-End-Auswahl und das Routing auf Endpunktebene konfiguriert.

  1. Speichern Sie das folgende Manifest als my-backend-policy.yaml:

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  # Attach to the super-service Service.
  targetRef:
    kind: Service
    name: super-service
  default:
    backends:
    # Configuration for all locations.
    - location: "*"
      # Use the rate balancing mode for the load balancer.
      balancingMode: RATE
      # Maximum number of requests per second for each endpoint.
      maxRatePerEndpoint: 9000
    # Configuration for us-central1-a
    - location: us-central1-a
      # maxRatePerEndpoint: 9000 inherited from the * configuration.
      # Use the custom metrics balancing mode for the load balancer.
      balancingMode: CUSTOM_METRICS
      # Configure the custom metrics for the load balancer to use.
      customMetrics:
      - name: gpu-load
        maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
        dryRun: false

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-backend-policy.yaml

Der Load Balancer verteilt den Traffic basierend auf dem RATE-Balancing-Modus und dem benutzerdefinierten gpu-load-Messwert.

Routing auf Endpunktebene mit GCPTrafficDistributionPolicy konfigurieren

Die GCPTrafficDistributionPolicy API in Google Kubernetes Engine (GKE) Gateway bietet erweiterte Funktionen zur Traffic-Verwaltung, mit denen Sie genau steuern können, wie Traffic an Ihre Anwendungs-Pods verteilt wird. Diese einheitliche, GKE-native Ressource vereinfacht die Verwaltung von Load-Balancing-Algorithmen und Einstellungen für die Sitzungsaffinität.

Mit der GCPTrafficDistributionPolicy können Sie Folgendes konfigurieren:

  • Load-Balancing-Algorithmen: Geben Sie an, wie der Traffic auf die Endpunkte in einem Backend verteilt wird.

    • WEIGHTED_ROUND_ROBIN: Wenn Sie diesen Algorithmus auswählen, verwendet der Load Balancer benutzerdefinierte Messwerte, um Gewichte zu berechnen und den Traffic basierend auf diesen gemeldeten Messwerten zu verteilen. Das customMetrics[]-Array in der GCPTrafficDistributionPolicy-Konfiguration enthält die folgenden Felder:

      • name: Gibt den benutzerdefinierten Namen des benutzerdefinierten Messwerts an.
      • dryRun: Wenn true, werden die Messwertdaten an Cloud Monitoring gemeldet, haben aber keinen Einfluss auf den Lastenausgleich.

  • RING_HASH: Dieser Algorithmus ist für Dienste von Vorteil, die empfindlich auf die Cacheleistung reagieren. Es wird konsistentes Hashing verwendet, um das Neuzuordnen von Anfragen zu minimieren, wenn Back-End-Pods hinzugefügt oder entfernt werden. Dies trägt zur Stabilität bei Skalierungsereignissen bei. Durch die Konfiguration des Felds minimumHashRingSize lässt sich die Lastverteilung genauer steuern.

  • Sitzungsaffinität: Damit wird sichergestellt, dass Anfragen vom selben Client immer an denselben Backend-Pod weitergeleitet werden. Das ist entscheidend für zustandsbehaftete Arbeitslasten wie E-Commerce-Einkaufswagen oder Gaming-Sitzungen. GKE Gateway verwendet GCPTrafficDistributionPolicy, um alle auf Google Cloud-Application Load Balancer-Instanzen verfügbaren Arten der Sitzungsaffinität zu unterstützen, einschließlich STRONG_COOKIE_AFFINITY, HEADER_FIELD, HTTP_COOKIE, GENERATED_COOKIE und CLIENT_IP.

Weitere Informationen finden Sie unter Trafficverwaltung mit benutzerdefinierten Messwerten für das Load-Balancing.

Beispiel

Das folgende Beispiel zeigt ein GCPTrafficDistributionPolicy-Manifest, das das Routing auf Endpunktebene mit dem WEIGHTED_ROUND_ROBIN-Load-Balancing-Algorithmus und benutzerdefinierten Messwerten konfiguriert.

  1. Speichern Sie das folgende Beispielmanifest als GCPTrafficDistributionPolicy.yaml:

    apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: echoserver-v2
  namespace: team1
spec:
  targetRefs:
  # Attach to the echoserver-v2 Service in the cluster.
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    # Use custom metrics to distribute traffic across endpoints.
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    # Configure metrics from an ORCA load report to use for traffic
    # distribution.
    customMetrics:
    - name: orca.named_metrics.bescm11
      dryRun: false
    - name: orca.named_metrics.bescm12
      dryRun: true

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f GCPTrafficDistributionPolicy.yaml

Der Load-Balancer verteilt den Traffic auf Endpunkte basierend auf dem WEIGHTED_ROUND_ROBIN-Algorithmus und den bereitgestellten benutzerdefinierten Messwerten.

Hash-Ring-Größe konfigurieren

Verwenden Sie für Dienste, bei denen das Minimieren von Cache-Fehlern entscheidend ist, den RING_HASH-Algorithmus. Durch Anpassen des Felds minimumHashRingSize lässt sich die Lastverteilung auf die Back-Ends präziser steuern. Der Load-Balancer verwaltet die Ringgröße automatisch. Wenn Sie jedoch einen höheren Mindestwert angeben, kann dies bei größeren Backend-Sets zu einer gleichmäßigeren Verteilung der Anfragen beitragen.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-service

Sitzungsaffinität konfigurieren

Konfigurieren Sie die Sitzungsaffinität, um sicherzustellen, dass Anfragen vom selben Client immer an denselben Backend-Pod weitergeleitet werden.

Sitzungsaffinität mit GCPTrafficDistributionPolicy konfigurieren (Standard)

Für die in diesem Abschnitt beschriebenen Sitzungsaffinitätstypen sind die folgenden GKE-Mindestversionen erforderlich:

  • CLIENT_IP, HEADER_FIELD, GENERATED_COOKIE und HTTP_COOKIE:Version 1.35.2-gke.1269001 oder höher.
  • STRONG_COOKIE_AFFINITY:Version 1.36.3-gke.1767000 oder höher.

GKE Gateway unterstützt alle Arten von Sitzungsaffinität mithilfe der Ressource „GCPTrafficDistributionPolicy“. Diese Ressource bietet eine detailliertere Steuerung, z. B. Routing basierend auf benutzerdefinierten HTTP-Headern oder Cookies. Die Konfiguration der Sitzungsaffinität mit GCPTrafficDistributionPolicy ist die Standardmethode und wird empfohlen.

In der folgenden Tabelle werden die Affinitätstypen beschrieben, die bei Verwendung von GCPTrafficDistributionPolicy unterstützt werden:

Affinitätstyp Beschreibung
STRONG_COOKIE_AFFINITY Zustandsorientierte cookiebasierte Sitzungspersistenz. Sorgt für eine hohe Sitzungsstabilität bei Skalierungsereignissen und Änderungen der Pod-Poolgröße. Sie müssen das Feld cookie.name konfigurieren und können optional die Felder cookie.path und cookie.ttl konfigurieren. Funktioniert mit jeder localityLbAlgorithm-Einstellung (der Standardwert ist ROUND_ROBIN).
HTTP_COOKIE Affinität basierend auf einem HTTP-Cookie. Wenn der Load-Balancer auf die erste Anfrage antwortet, generiert er ein Cookie und stellt es in einem Set-Cookie-Antwortheader bereit. Bei nachfolgenden Anfragen gibt der Client das vom Load-Balancer bereitgestellte Cookie zurück. Der Load-Balancer verwendet es, um Anfragen konsistent an dieselben Pods weiterzuleiten. Sie müssen das Feld cookie.name konfigurieren und können optional die Felder cookie.path und cookie.ttl konfigurieren. Erfordert, dass das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH gesetzt ist.
GENERATED_COOKIE Der Load-Balancer generiert ein Cookie, um die Sitzung zu verfolgen. Der Name des Cookies ist GCLB für globale externe Application Load Balancer und GCILB für regionale interne Application Load Balancer und regionale externe Application Load Balancer. Der Cookie-Pfad ist /. Optional können Sie das Feld cookie.ttl für einen Zeitraum von bis zu zwei Wochen konfigurieren. Die Felder cookie.name und cookie.path sind für diesen Typ nicht konfigurierbar. Erfordert, dass das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH gesetzt ist.
HEADER_FIELD Affinität basierend auf einem bestimmten HTTP-Header. Erfordert, dass das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH gesetzt ist.
CLIENT_IP Affinität basierend auf der IP-Adresse des Clients. Erfordert, dass das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH gesetzt ist.
NONE Deaktiviert die Sitzungsaffinität.

Die folgenden Beispiele zeigen, wie Sie die GCPTrafficDistributionPolicy nach Affinitätskategorie konfigurieren: Cookie-basierte, headerbasierte und Client-IP-basierte Sitzungsaffinität.

So wenden Sie eine der folgenden Konfigurationen für die Sitzungsaffinität auf Ihren Cluster an:

  1. Speichern Sie das ausgewählte Manifest als policy.yaml.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f policy.yaml

Die cookiebasierte Sitzungsaffinität umfasst die Affinitätstypen STRONG_COOKIE_AFFINITY, HTTP_COOKIE und GENERATED_COOKIE.

Zustandsorientierte Cookie-Affinität (STRONG_COOKIE_AFFINITY)

Die zustandsorientierte Cookie-Affinität (STRONG_COOKIE_AFFINITY) bietet eine zustandsorientierte Sitzungspersistenz, die die Stickiness auch während des Backend-Scalings beibehält.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: strong-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: STRONG_COOKIE_AFFINITY
      cookie:
        name: "GKE_STATEFUL_SESSION"
        path: "/"
        ttl: "24h"
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

HTTP-Cookie-Affinität (HTTP_COOKIE)

Beim Affinitätstyp HTTP_COOKIE basiert die Affinität auf einem bestimmten benannten Cookie, das in einem Set-Cookie-Header zurückgegeben wird. Wenn Sie andere Sitzungsaffinitätstypen als NONE und STRONG_COOKIE_AFFINITY verwenden möchten, müssen Sie das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH festlegen.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: http-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HTTP_COOKIE
      cookie:
        name: "my-app-session-id"
        path: "/"
        ttl: "3600s"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Generierte Cookie-Affinität (GENERATED_COOKIE)

Mit dem Affinitätstyp GENERATED_COOKIE kann der Load-Balancer das Sitzungscookie automatisch generieren und benennen. Optional können Sie den Wert des Felds cookie.ttl auf bis zu zwei Wochen (336h) konfigurieren.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: generated-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookie:
        ttl: "2h30m"
    # GENERATED_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Das Verhalten bei einer TTL von null für die Cookie-basierte Sitzungsaffinität umfasst Folgendes:

  • Alle cookiebasierten Sitzungsaffinitäten (STRONG_COOKIE_AFFINITY, HTTP_COOKIE und GENERATED_COOKIE) haben das Attribut ttl.

  • Eine TTL von null Sekunden bedeutet, dass der Load-Balancer dem Cookie kein Expires-Attribut zuweist. In diesem Fall behandelt der Client das Cookie als Sitzungscookie. Die Definition einer Sitzung variiert je nach Client:

    • Einige Clients, z. B. Webbrowser, behalten das Cookie für die gesamte Browsersitzung bei. Bei diesem Ansatz bleibt das Cookie über mehrere Anfragen hinweg bestehen, bis die Anwendung geschlossen wird.
    • Andere Clients behandeln eine Sitzung als einzelne HTTP-Anfrage und verwerfen das Cookie sofort nach Ende der Sitzung.

Header-basierte Sitzungsaffinität

Beim Affinitätstyp HEADER_FIELD wird Traffic anhand eines bestimmten HTTP-Headers weitergeleitet. Das ist z. B. bei A/B-Tests oder beim Routing von spezialisierten Clients sinnvoll, wenn ein Cookie nicht geeignet ist. Wenn Sie andere Sitzungsaffinitätstypen als NONE und STRONG_COOKIE_AFFINITY verwenden möchten, müssen Sie das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH festlegen. Im Gegensatz zum Standard-ROUND_ROBIN unterstützen diese Algorithmen konsistentes Hashing basierend auf benutzerdefinierten Feldern wie HTTP-Headern.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: header-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HEADER_FIELD
      httpHeaderName: "X-User-Group-ID"
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Sitzungsaffinität auf Basis von Client-IP-Adressen

Mit dem Affinitätstyp CLIENT_IP wird Traffic von einer bestimmten Client-IP-Adresse auf Best-Effort-Basis an denselben Backend-Pod weitergeleitet. Wenn Sie andere Sitzungsaffinitätstypen als NONE und STRONG_COOKIE_AFFINITY verwenden möchten, müssen Sie das Feld localityLbAlgorithm auf MAGLEV oder RING_HASH setzen.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: client-ip-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Richtlinie überprüfen

So prüfen Sie, ob Ihre GCPTrafficDistributionPolicy richtig konfiguriert und aktiv ist:

  1. Führen Sie den folgenden Befehl aus, um den Status der Richtlinie zu prüfen:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ersetzen Sie POLICY_NAME durch den Namen Ihrer Richtlinie.

  2. Sehen Sie sich in der Ausgabe den Abschnitt Conditions an. Der Status True mit dem Grund Attached gibt an, dass die Konfiguration gültig und aktiv ist.

Sitzungsaffinität mit GCPBackendPolicy konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Sitzungsaffinität mit GCPBackendPolicy konfigurieren.

Sie können die Sitzungsaffinität für GCPBackendPolicy anhand der folgenden Kriterien konfigurieren:

  • Client-IP-Adresse (CLIENT_IP)
  • Generiertes Cookie (GENERATED_COOKIE)

Wenn Sie die Sitzungsaffinität für Ihren Dienst mit GCPBackendPolicy konfigurieren, legt das Gateway die Einstellung localityLbPolicy für den Backend-Dienst auf MAGLEV fest. Wenn Sie die Sitzungsaffinität aus der 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:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    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:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    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:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  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:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-Cluster-InferencePool

yaml apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: my-backend-policy namespace: lb-service-namespace spec: default: connectionDraining: drainingTimeoutSec: 60 # Attach to a multi-cluster InferencePool. targetRef: group: networking.gke.io kind: GCPInferencePoolImport name: my-inference-pool-import

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 Stichprobenrate beträgt 1.000.000. Das bedeutet, dass alle Anfragen protokolliert werden.
  • Es werden keine optionalen Felder protokolliert.

Sie haben drei Möglichkeiten, das Zugriffs-Logging für Ihr Gateway mit einer GCPBackendPolicy zu deaktivieren:

  • Sie können die GCPBackendPolicy ohne logging-Abschnitt lassen.
  • 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 und eine Liste optionaler Felder wie tls.cipher oder orcaLoadReport konfigurieren.

So aktivieren Sie das Logging der optionalen Felder:

  • Setzen Sie logging.OptionalMode auf CUSTOM.
  • Geben Sie die Liste der optionalen Felder an, die protokolliert werden sollen, indem Sie logging.optionalFields verwenden. Eine Liste der unterstützten Felder finden Sie unter Logging und Monitoring.

Sie haben zwei Möglichkeiten, das Logging der optionalen Felder zu deaktivieren:

  • Sie können alle Einträge aus logging.optionalFields entfernen.
  • Sie können logging.OptionalMode auf EXCLUDE_ALL_OPTIONAL setzen.

Mit dem folgenden GCPBackendPolicy-Manifest wird die Standard-Stichprobenrate für das Zugriffs-Logging geändert und auf 50% der HTTP-Anfragen festgelegt. Das Manifest ermöglicht auch das Logging von zwei optionalen Feldern für eine bestimmte Service-Ressource:

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  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:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-Cluster-InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Dieses Manifest hat die folgenden Felder:

  • enable: true: Aktiviert das Zugriffs-Logging explizit. 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.
  • optionalMode: CUSTOM: Gibt an, dass eine Reihe von optionalFields in Logeinträge aufgenommen werden soll.
  • optionalFields: tls.cipher, orcaLoadReport.cpu_utilization: Gibt an, dass Logeinträge sowohl den Namen der für den TLS-Handshake verwendeten Chiffre als auch die CPU-Auslastung des Dienstes enthalten sollen, sofern diese verfügbar sind.

Traffic-basiertes Autoscaling für Ihr Single-Cluster-Gateway konfigurieren

Prüfen Sie, ob auf Ihrem GKE-Cluster die Version 1.31.1-gke.2008000 oder höher ausgeführt wird.

Wenn Sie traffic-basiertes Autoscaling und kapazitätsbasiertes Load-Balancing in einem Gateway mit einem einzelnen Cluster aktivieren möchten, können Sie die Dienstkapazität konfigurieren. Die Service-Kapazität ist die Möglichkeit, die Menge an Traffic-Kapazität anzugeben, die ein Service empfangen kann, bevor Pods automatisch skaliert werden oder der Traffic zu anderen verfügbaren Clustern überläuft.

Erstellen Sie zum Konfigurieren der Service-Kapazität einen Service und eine zugehörige GCPBackendPolicy. Im GCPBackendPolicy-Manifest wird das Feld maxRatePerEndpoint verwendet, das einen maximalen Wert für Anfragen pro Sekunde (Requests per Second, RPS) pro Pod in einem Service definiert. Das folgende GCPBackendPolicy-Manifest definiert eine maximale Anzahl von Anfragen pro Sekunde von 10:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

Weitere Informationen zum traffic-basierten Autoscaling finden Sie unter Autoscaling auf Basis des Load-Balancer-Traffics.

Fehlerbehebung

Dieser Abschnitt enthält Hinweise zur Behebung häufiger Probleme bei der Konfiguration von Gateway-Ressourcen mithilfe von Richtlinien.

GCPTrafficDistributionPolicy wird nicht wirksam

Symptom:Der Traffic wird nicht gemäß den in Ihrer Richtlinie definierten Einstellungen für die Sitzungsaffinität oder den Standort verteilt.

Ursache:Dies tritt in der Regel auf, wenn die Richtlinie nicht korrekt an den Dienst gebunden ist oder wenn der Gateway-Controller beim Versuch, die Konfiguration mit dem Load Balancer zu synchronisieren, einen Validierungsfehler festgestellt hat.

Workaround:

  1. Richtlinienstatus prüfen: Prüfen Sie, ob die Richtlinie an Ihren Dienst angehängt wurde:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ersetzen Sie POLICY_NAME durch den Namen Ihrer Richtlinie.

    Suchen Sie in der Ausgabe nach dem Abschnitt Conditions. Der Status True mit dem Grund Attached gibt an, dass die Konfiguration gültig ist und angewendet wurde. Wenn der Status False lautet, prüfen Sie die Felder Reason und Message auf Validierungsfehler, z. B. einen nicht unterstützten Algorithmus für den ausgewählten Affinitätstyp.

  2. Synchronisierung der Gateway-Konfiguration prüfen: Prüfen Sie, ob das Gateway, das den Traffic verwaltet, diese Einstellungen erfolgreich mit der Cloud-Infrastruktur synchronisiert hat.

    Prüfen Sie im Abschnitt Status, ob die Bedingung Programmed den Status-Wert True hat. Wenn der Wert False ist, weist dies darauf hin, dass beim Gateway-Controller ein Fehler aufgetreten ist, der möglicherweise mit Ihrer GCPTrafficDistributionPolicy zusammenhängt.

    Sehen Sie sich die Felder Reason und Message neben der Bedingung Programmed an, um sofort Details zu erhalten. Detailliertere Fehlermeldungen oder einen Verlauf der Synchronisierungsfehler finden Sie unten in der Ausgabe unter Events.

Mehrere GCPBackendPolicys, die mit demselben Dienst verknüpft sind

Symptom:

Die folgende Statusbedingung kann auftreten, wenn Sie eine GCPBackendPolicy an einen Dienst oder einen 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 Dienst oder ServiceImport anzuwenden, dem bereits eine GCPBackendPolicy zugewiesen ist.

Mehrere GCPBackendPolicys, die mit demselben Service oder ServiceImport verknüpft 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 die Zielressource (Service, ServiceImport, InferencePool oder GCPInferencePoolImport) an.

Sitzungsaffinität wird bei der Trafficaufteilung ignoriert

Symptom:

Anfragen werden nicht konsistent an denselben Backend-Pod weitergeleitet, obwohl die Sitzungsaffinität konfiguriert ist.

Grund:

Die gewichtete Trafficaufteilung hat Vorrang vor der Sitzungsaffinität. Wenn in einer HTTPRoute Gewichte für mehrere Back-Ends definiert sind, wählt der Load-Balancer zuerst ein Back-End basierend auf den Gewichten aus, bevor er die Affinitätslogik anwendet.

Workaround:

Vermeiden Sie die Verwendung der gewichteten Trafficaufteilung für dieselbe HTTPRoute-Regel, für die die Sitzungsaffinität erforderlich ist.

Cloud Armor-Sicherheitsrichtlinie nicht gefunden

Symptom:

Die folgende Fehlermeldung kann angezeigt werden, wenn Sie Cloud Armor für Ihr regionales Gateway aktivieren:

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

Grund:

Die Fehlermeldung gibt an, dass die angegebene regionale Cloud Armor-Sicherheitsrichtlinie in Ihrem Google Cloud Projekt nicht vorhanden ist.

Workaround:

Erstellen Sie eine regionale Cloud Armor-Sicherheitsrichtlinie in Ihrem Projekt und verweisen Sie in Ihrer GCPBackendPolicy auf diese Richtlinie.

Nächste Schritte