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.

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 diesen Task 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 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:

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

  • Einem Dienst kann jeweils nur ein GCPBackendPolicy angehängt werden. Wenn zwei GCPBackendPolicy-Richtlinien erstellt wurden, die auf denselben Service 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 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. Verwenden Sie für die Sitzungsaffinität HEADER_FIELD oder HTTP_COOKIE die GCPTrafficDistributionPolicy-Ressource.

  • Wenn Sie Gateways mit unterschiedlichen Bereichen verwenden (z. B. global extern und regional intern), können Sie nicht dasselbe Backend Service verwenden, wenn dafür unterschiedliche GCPBackendPolicy-Konfigurationen erforderlich sind. Ein globales GCPBackendPolicy kann beispielsweise nicht auf ein Gateway mit regionalem Bereich angewendet werden und umgekehrt. Damit die richtlinienspezifischen Bereiche korrekt sind, erstellen Sie für jeden Gateway-Bereich ein separates Service.

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

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

  • GCPTrafficDistributionPolicy unterstützt nicht das Konfigurieren von Sitzungsaffinität oder Ort-Load-Balancing-Richtlinien für den klassischen Application Load Balancer.

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

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-HealthCheck 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 Clouderstellt eine eindeutige Systemdiagnose für jeden Backend-Dienst für jeden GKE-Dienst.

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

# 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

Ersetzen Sie dabei 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 für Google Cloud 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: 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 die Protokollierung 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 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 auf die Richtlinie in Ihrer GCPBackendPolicy verweisen. Wenn Sie ein regionales Gateway aktivieren, müssen Sie eine regionale Cloud Armor-Back-End-Sicherheitsrichtlinie erstellen.

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:
    # 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

IAP konfigurieren

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. 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, der im GCPBackendPolicy als Ziel verwendet werden soll.

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

Backend-Auswahl mit GCPBackendPolicy konfigurieren

Mit dem CUSTOM_METRICS-Load-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 basierend auf benutzerdefinierten Messwerten durchgeführt, die Sie definieren und die von den Anwendungs-Back-Ends gemeldet werden.

Weitere Informationen finden Sie unter Trafficverwaltung mit benutzerdefinierten messwertbasierten 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, in dem benutzerdefinierte Messwerte für die Backend-Auswahl und das Routing auf Endpunktebene konfiguriert werden.

  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 anhand des RATE-Load-Balancing-Modus und des benutzerdefinierten gpu-load-Messwerts.

Routing auf Endpunktebene mit GCPTrafficDistributionPolicy konfigurieren

Die GCPTrafficDistributionPolicy API in Google Kubernetes Engine (GKE) Gateway bietet erweiterte Funktionen zur Trafficverwaltung, 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 dem 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 Consistent Hashing verwendet, um das Neuzuordnen von Anfragen zu minimieren, wenn Back-End-Pods hinzugefügt oder entfernt werden. So wird die Stabilität bei Skalierungsereignissen verbessert. Durch die Konfiguration von minimumHashRingSize wird die Lastverteilung detaillierter.

  • Sitzungsaffinität: Damit wird dafür gesorgt, dass Anfragen von demselben Client immer an denselben Backend-Pod weitergeleitet werden. Das ist entscheidend für zustandsbehaftete Arbeitslasten wie E-Commerce-Warenkörbe oder Gaming-Sitzungen. GKE Gateway unterstützt alle Arten von Sitzungsaffinität, die fürGoogle Cloud Application Load Balancer-Instanzen verfügbar sind, einschließlich HEADER_FIELD und HTTP_COOKIE.

Weitere Informationen finden Sie unter Trafficverwaltung mit benutzerdefinierten messwertbasierten Load-Balancing.

Beispiel

Das folgende Beispiel zeigt ein GCPTrafficDistributionPolicy-Manifest, in dem das Routing auf Endpunktebene sowohl mit dem WEIGHTED_ROUND_ROBIN-Load-Balancing-Algorithmus als auch mit benutzerdefinierten Messwerten konfiguriert wird.

  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.

Größe des Hash-Rings konfigurieren

Verwenden Sie für Dienste, bei denen das Minimieren von Cache-Fehlern entscheidend ist, den RING_HASH-Algorithmus. Durch Anpassen von minimumHashRingSize lässt sich die Lastverteilung auf die Back-Ends genauer 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

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:

  • Client-IP-Adresse
  • 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:
    # 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

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

  • CLIENT_IP
  • GENERATED_COOKIE
  • NONE

Erweiterte Sitzungsaffinität mit GCPTrafficDistributionPolicy

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

GKE Gateway unterstützt erweiterte Sitzungsaffinitätstypen mithilfe der GCPTrafficDistributionPolicy-Ressource. Dies ermöglicht eine detailliertere Steuerung, z. B. Routing basierend auf benutzerdefinierten HTTP-Headern oder Cookies, die vom Load-Balancer generiert werden.

Hinweis:Für die erweiterte Sitzungsaffinität verwenden Sie GCPTrafficDistributionPolicy. GCPBackendPolicy unterstützt zwar auch bestimmte Arten von Sitzungsaffinität, gilt aber als Legacy-Option für diese Konfiguration. Wenn beide Richtlinien auf denselben Dienst ausgerichtet sind, hat die GCPTrafficDistributionPolicy-Konfiguration Vorrang.

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

Typ der Zielgruppe mit gemeinsamen Interessen Beschreibung
HEADER_FIELD Affinität basierend auf einem bestimmten HTTP-Header. Erfordert, dass localityLbAlgorithm auf MAGLEV oder RING_HASH festgelegt ist.
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 die Anfragen konsistent an dieselben Pods weiterzuleiten. Sie müssen cookie.name konfigurieren und können optional cookie.path und cookie.ttl konfigurieren. Erfordert, dass localityLbAlgorithm auf MAGLEV oder RING_HASH festgelegt 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 cookie.ttl auf maximal zwei Wochen konfigurieren. cookie.name und cookie.path sind für diesen Typ nicht konfigurierbar. Erfordert, dass localityLbAlgorithm auf MAGLEV oder RING_HASH festgelegt ist.
CLIENT_IP Affinität basierend auf der IP-Adresse des Clients. Erfordert, dass localityLbAlgorithm auf MAGLEV oder RING_HASH festgelegt ist.

Erweiterte Beispiele für die Sitzungsaffinität

GCPTrafficDistributionPolicy unterstützt mehrere Arten von Sitzungsaffinität, die jeweils eigene Konfigurationsanforderungen haben.

Bei zustandsorientierten Anwendungen wie Einkaufswagen oder Gaming-Servern sollten Anfragen an den jeweiligen Pod weitergeleitet werden, der die Sitzungsdaten des Nutzers enthält. Bei dieser Konfiguration wird die HTTP_COOKIE-Affinität verwendet, bei der die Sitzungsaffinität auf einem bestimmten Cookie basiert, das vom Load Balancer generiert und im Set-Cookie-Header an den Client zurückgegeben wird.

  1. Speichern Sie das folgende Manifest als policy.yaml:

    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"
        ttl: "1h"
        path: "/"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: my-stateful-service

  2. Wenden Sie die Richtlinie auf Ihren Cluster an:

    kubectl apply -f policy.yaml

Verhalten bei einer TTL von null für die cookiebasierte Sitzungsaffinität:

Alle cookiebasierten Sitzungsaffinitäten, z. B. GENERATED_COOKIE- und HTTP_COOKIE-Affinität, haben ein ttl-Attribut.

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. Das bedeutet, dass das Cookie über mehrere Anfragen hinweg bestehen bleibt, bis die Anwendung geschlossen wird.
  • Andere Clients behandeln eine Sitzung als einzelne HTTP-Anfrage und verwerfen das Cookie sofort danach.
Header-basierte Sitzungsaffinität konfigurieren

Traffic anhand eines bestimmten HTTP-Headers weiterleiten, z. B. für A/B-Tests oder spezielles Client-Routing, bei dem ein Cookie nicht geeignet ist. Wenn Sie andere Sitzungsaffinitätstypen als NONE verwenden möchten, müssen Sie localityLbAlgorithm auf MAGLEV oder RING_HASH festlegen. Im Gegensatz zum Standard-ROUND_ROBIN unterstützen diese Algorithmen konsistente Hashfunktion basierend auf benutzerdefinierten Feldern wie HTTP-Headern.

  1. Speichern Sie das folgende Manifest als policy.yaml:

    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

  2. Wenden Sie die Richtlinie auf Ihren Cluster an:

    kubectl apply -f policy.yaml
Richtlinie überprüfen

Prüfen Sie nach der Anwendung des GCPTrafficDistributionPolicy-Tags den Status, um sicherzugehen, dass er richtig konfiguriert und aktiv ist.

  1. So prüfen Sie den Status der Richtlinie:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ersetzen Sie POLICY_NAME durch den Namen Ihrer Richtlinie.

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

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 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 einem GCPBackendPolicy zu deaktivieren:

  • Sie können den Abschnitt GCPBackendPolicy ohne logging 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 konfigurieren, z. B. „tls.cipher“ oder „orca_load_report“.

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
      - orca_load_report.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
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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, orca_load_report.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. Mit der Service-Kapazität können Sie die Menge an Traffic-Kapazität angeben, 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 die Anfragen pro Sekunde (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 Anleitungen 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 Ihrem 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 GCPBackendPolicy, die an dieselbe Service angehängt sind

Symptom:

Der folgende Status kann auftreten, wenn Sie ein GCPBackendPolicy an ein Service oder ein 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:

Dieser Status gibt an, dass Sie versuchen, eine zweite GCPBackendPolicy auf eine Service oder ServiceImport anzuwenden, der bereits eine GCPBackendPolicy zugewiesen ist.

Mehrere GCPBackendPolicy, 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 mit allen benutzerdefinierten Konfigurationen und hängen Sie sie an Ihre Service oder ServiceImport 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 einem HTTPRoute Gewichte für mehrere Backends definiert sind, wählt der Load Balancer zuerst ein Backend 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 auf Ihrem regionalen 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