Gateway-Ressourcen mithilfe von Richtlinien konfigurieren

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

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

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

Hinweise

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:

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

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

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

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

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

  • Hierarchische Richtlinien werden 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 die Optionen HEADER_FIELD oder HTTP_COOKIE für die Sitzungsaffinität nicht.

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: 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 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 Bereitstellungsport (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

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

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

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

So konfigurieren Sie IAP mit Gateway:

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

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

    1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf:

      Zu den Anmeldedaten

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

    3. Kopieren Sie den OAuth-Schlüssel aus der OAuth-Clientdatei in die Zwischenablage.

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

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

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

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

    1. Erstellen Sie das folgende GCPBackendPolicy-Manifest und ersetzen Sie SECRET_NAME und CLIENT_ID entsprechend. Speichern Sie das 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: SECRET_NAME
      clientID: CLIENT_ID
  # 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: 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: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

      kubectl apply -f backend-policy.yaml

  4. Konfiguration überprüfen:

    1. Prüfen Sie, ob die Richtlinie 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
        maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [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-Load-Balancing-Modus und dem benutzerdefinierten gpu-load-Messwert.

Routing auf Endpunktebene mit GCPTrafficDistributionPolicy konfigurieren

Mit GCPTrafficDistributionPolicy wird der Load-Balancing-Algorithmus für die Auswahl von Endpunkten innerhalb eines Backends konfiguriert. Wenn Sie WEIGHTED_ROUND_ROBIN auswählen, verwendet der Load Balancer Gewichte, die aus gemeldeten Messwerten (einschließlich benutzerdefinierter Messwerte) abgeleitet werden, um den Traffic auf einzelne Instanzen oder Endpunkte zu verteilen.

Das Feld WEIGHTED_ROUND_ROBIN localityLbPolicy der Ressource GCPTrafficDistributionPolicy gibt einen Load-Balancing-Algorithmus zum Auswählen einzelner Instanzen oder Endpunkte innerhalb eines Back-Ends an. Wenn Sie diesen Algorithmus verwenden, werden in der Richtlinie benutzerdefinierte Messwerte verwendet, um Gewichte für die Lastzuweisung zu berechnen.

Das customMetrics[]-Array in der GCPTrafficDistributionPolicy-Konfiguration enthält die folgenden Felder:

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

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 anhand des WEIGHTED_ROUND_ROBIN-Algorithmus und der bereitgestellten benutzerdefinierten Messwerte auf die Endpunkte.

Sitzungsaffinität konfigurieren

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

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

  • IP-Adresse des Clients
  • Generiertes Cookie

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

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

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

Dienst

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # 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

Zeitlimit für Verbindungsausgleich konfigurieren

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

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

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

Dienst

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

Multi-Cluster-Dienst

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

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

HTTP-Zugriffs-Logging

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

Standard:

  • Der Gateway-Controller protokolliert alle HTTP-Anfragen von Clients in Cloud Logging.
  • Die Abtastrate beträgt 1.000.000. Das bedeutet, dass alle Anfragen protokolliert werden.
  • 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-Abtastrate 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 Protokolleinträ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

Mehrere GCPBackendPolicy, die mit demselben Service verknüpft 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, die bereits eine GCPBackendPolicy hat.

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.

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