Configurare le risorse del gateway utilizzando i criteri

Questa pagina mostra come configurare il bilanciatore del carico che Google Kubernetes Engine (GKE) crea quando esegui il deployment di un gateway in un cluster GKE.

Quando esegui il deployment di un gateway, la configurazione di GatewayClass determina quale bilanciatore del carico crea GKE. Questo bilanciatore del carico gestito è preconfigurato con impostazioni predefinite che puoi modificare utilizzando un criterio.

Puoi personalizzare le risorse Gateway in base ai requisiti dell'infrastruttura o dell'applicazione collegando le policy a gateway, servizi o ServiceImport. Dopo aver applicato o modificato un criterio, il controller Gateway lo elabora e riconfigura automaticamente la risorsa di bilanciamento del carico sottostante. In questo modo si elimina la necessità di eliminare o ricreare le risorse Gateway, Route o Service.

Puoi anche utilizzare una risorsa BackendTLSPolicy per configurare le impostazioni TLS autenticato dal backend per verificare l'identità dei backend a cui si connette il gateway. Per saperne di più, consulta Configura TLS backend.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Requisiti del controller GKE Gateway

  • L'API Gateway è supportata solo sui cluster VPC nativi.
  • Se utilizzi GatewayClass regionali o tra regioni, devi attivare una subnet solo proxy.
  • Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato.
  • Se utilizzi Istio, devi eseguire l'upgrade a una delle seguenti versioni:
    • 1.15.2 o versioni successive
    • 1.14.5 o versioni successive
    • 1.13.9 o versioni successive.
  • Se utilizzi un VPC condiviso, nel progetto host devi assegnare il ruolo Compute Network User al service account GKE per il progetto di servizio.

Restrizioni e limitazioni

Oltre alle limitazioni e alle limitazioni del controller GKE Gateway, le seguenti limitazioni si applicano in modo specifico ai criteri applicati alle risorse Gateway:

  • Le risorse GCPGatewayPolicy possono essere collegate solo a un gateway gateway.networking.k8s.io.

  • Le risorse GCPGatewayPolicy devono esistere nello stesso spazio dei nomi del gateway di destinazione.

  • Quando utilizzi un singolo cluster Gateway, le risorse GCPBackendPolicy e HealthCheckPolicy devono fare riferimento a una risorsa Service.

  • Quando utilizzi un gateway multi-cluster, GCPBackendPolicy e HealthCheckPolicy, le risorse devono fare riferimento a una risorsa ServiceImport.

  • A un servizio può essere collegata una sola GCPBackendPolicy alla volta. Quando vengono create due policy GCPBackendPolicy che hanno come target lo stesso servizio o la stessa importazione di servizi, ha la precedenza la policy meno recente e il collegamento della seconda non riesce.

  • Le policy gerarchiche non sono supportate con GKE Gateway.

  • Le risorse HealthCheckPolicy e GCPBackendPolicy devono esistere nello stesso spazio dei nomi della risorsa Service o ServiceImport di destinazione.

  • Le risorse GCPBackendPolicy e HealthCheckPolicy sono strutturate in modo da poter fare riferimento a un solo servizio di backend.

  • GCPBackendPolicy non supporta le opzioni HEADER_FIELD o HTTP_COOKIE per l'affinità sessione. Per l'affinità sessione HEADER_FIELD o HTTP_COOKIE, utilizza la risorsa GCPTrafficDistributionPolicy.

  • Non utilizzare lo stesso servizio di backend in gateway di diversi tipi di GatewayClass (ad esempio globale e regionale, interno ed esterno o gestito e classico) se questi gateway richiedono configurazioni incompatibili. Ad esempio, una GCPBackendPolicy configurata con funzionalità non supportate da una GatewayClass "Classic" non può essere applicata a un servizio utilizzato anche da un gateway "Classic". Per garantire una configurazione corretta, crea un servizio distinto per ogni gateway che richiede impostazioni delle norme diverse.

  • L'affinità sessione configurata utilizzando un GCPTrafficDistributionPolicy è supportata solo per i gateway a cluster singolo.

  • L'affinità sessione di GCPTrafficDistributionPolicy non è compatibile con le risorse InferencePool perché utilizzano algoritmi di bilanciamento del carico per località dedicati.

  • GCPTrafficDistributionPolicy non supporta la configurazione dell'affinità sessione o delle policy di bilanciamento del carico per le località per il bilanciatore del carico delle applicazioni classico.

  • Quando utilizzi un gateway a singolo cluster, le risorse GCPBackendPolicy e HealthCheckPolicy devono fare riferimento a una risorsa Service o InferencePool.

  • Quando utilizzi un gateway multi-cluster, le risorse GCPBackendPolicy e HealthCheckPolicy devono fare riferimento a una risorsa ServiceImport o GCPInferencePoolImport.

  • Può essere collegato a una singola risorsa di destinazione (Service, ServiceImport, InferencePool o GCPInferencePoolImport) solo un GCPBackendPolicy alla volta. Quando vengono create più risorse GCPBackendPolicy che hanno come target la stessa risorsa, la policy meno recente ha la precedenza e quella più recente non viene collegata.

  • Le risorse HealthCheckPolicy e GCPBackendPolicy devono esistere nello stesso spazio dei nomi della risorsa Service, ServiceImport, InferencePool o GCPInferencePoolImport di destinazione.

  • Le risorse GCPBackendPolicy e HealthCheckPolicy possono avere come target una singola risorsa (ad esempio un servizio o un InferencePool).

Best practice: crea un servizio distinto per ogni gateway utilizzando una GatewayClass diversa per garantire la compatibilità tra le policy del servizio e il tipo di bilanciatore del carico.

Configurare l'accesso globale per il gateway interno regionale

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Per abilitare l'accesso globale con il gateway interno, collega una policy alla risorsa gateway.

Il seguente manifest GCPGatewayPolicy abilita il gateway interno regionale per l'accesso globale:

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

Configura la regione per il gateway multi-cluster

Questa sezione descrive una funzionalità disponibile sui cluster GKE con versione 1.30.3-gke.1225000 o successive.

Se la tua flotta ha cluster in più regioni, potresti dover eseguire il deployment di gateway regionali in regioni diverse per una serie di casi d'uso, ad esempio, ridondanza tra regioni, bassa latenza e sovranità dei dati. Nel cluster di configurazione di Gateway multi-cluster, puoi specificare la regione in cui vuoi eseguire il deployment dei gateway regionali. Se non specifichi una regione, la regione predefinita è quella del cluster di configurazione.

Per configurare una regione per il gateway multi-cluster, utilizza il campo region in GCPGatewayPolicy. Nell'esempio seguente, il gateway è configurato nella regione us-central1:

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

Configura i criteri SSL per proteggere il traffico dal client al bilanciatore del carico

Questa sezione descrive le funzionalità disponibili sui cluster GKE che eseguono la versione 1.24 o successive.

Per proteggere il traffico dal client al bilanciatore del carico, configura la policy SSL aggiungendo il nome della policy a GCPGatewayPolicy. Per impostazione predefinita, il gateway non ha una policy SSL definita e collegata.

Assicurati di creare una policy SSL prima di fare riferimento alla policy nella risorsa GCPGatewayPolicy.

Il seguente manifest GCPGatewayPolicy specifica una policy di sicurezza denominata gke-gateway-ssl-policy:

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

Configura i controlli di integrità

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Per impostazione predefinita, per i servizi di backend che utilizzano i protocolli di applicazione HTTP o kubernetes.io/h2c, il controllo di integrità è di tipo HTTP. Per il protocollo HTTPS, il controllo di integrità predefinito è di tipo HTTPS. Per il protocollo HTTP2, il controllo di integrità predefinito è di tipo HTTP2.

Puoi utilizzare un HealthCheckPolicy per controllare le impostazioni del controllo di integrità del bilanciatore del carico. Ogni tipo di controllo di integrità (http, https, grpc, http2 e tcp) ha parametri che puoi definire. Google Cloud crea un controllo di integrità univoco per ogni servizio di backend per ogni servizio GKE.

Affinché il bilanciatore del carico funzioni normalmente, potrebbe essere necessario configurare un criterio HealthCheck personalizzato per il bilanciatore del carico se il percorso del controllo di integrità non è quello standard "/". Questa configurazione è necessaria anche se il percorso richiede intestazioni speciali o se devi modificare i parametri del controllo di integrità. Ad esempio, se il percorso di richiesta predefinito è "/", ma il tuo servizio non è accessibile a questo percorso di richiesta e utilizza invece "/health" per segnalare il suo stato, devi configurare requestPath in HealthCheckPolicy di conseguenza.

Il seguente manifest HealthCheckPolicy mostra tutti i campi disponibili durante la configurazione di una policy di controllo di integrità:

Servizio

# 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

Servizio multi-cluster

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

Sostituisci quanto segue:

  • INTERVAL: specifica l'intervallo di controllo, in secondi, per ogni sonda di controllo di integrità. È il tempo che intercorre tra l'inizio di un controllo di un prober e l'inizio del controllo successivo. Se ometti questo parametro, il valore predefinito di Google Cloud è 15 secondi se non viene specificato alcun HealthCheckPolicy ed è 5 secondi quando viene specificato un HealthCheckPolicy senza valore checkIntervalSec. Per saperne di più, consulta Più probe e frequenza.
  • TIMEOUT: specifica il tempo di attesa da parte diGoogle Cloud per una risposta a un probe. Il valore di TIMEOUT deve essere minore o uguale a INTERVAL. Il valore è espresso in secondi. Ogni sonda richiede la restituzione di un codice di risposta HTTP 200 (OK) prima del timeout della sonda.
  • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: specifica il numero di tentativi di connessione sequenziali che devono riuscire o non riuscire, per almeno un probe, per modificare lo stato di integrità da integro a non integro o da non integro a integro. Se ometti uno di questi parametri, il valore Google Cloud predefinito è 2.
  • PROTOCOL: specifica un protocollo utilizzato dai sistemi di probe per il controllo di integrità. Per saperne di più, consulta Criteri di esito positivo per HTTP, HTTPS e HTTP/2, Criteri di esito positivo per gRPC e Criteri di esito positivo per TCP. Questo parametro è obbligatorio.
  • ENABLED: specifica se la registrazione è abilitata o disabilitata.
  • PORT_SPECIFICATION: specifica se il controllo di integrità utilizza una porta fissa (USE_FIXED_PORT), una porta denominata (USE_NAMED_PORT) o una porta di servizio (USE_SERVING_PORT). Se non specificato, il controllo di integrità segue il comportamento specificato nel campo port. Se port non è specificato, questo campo ha come valore predefinito USE_SERVING_PORT.
  • PORT: un HealthCheckPolicy supporta solo la specifica della porta del controllo di integrità del bilanciatore del carico utilizzando un numero di porta. Se ometti questo parametro, il valore predefinito di Google Cloud è 80. Poiché il bilanciatore del carico invia probe direttamente all'indirizzo IP del pod, devi selezionare una porta corrispondente a un containerPort di un pod di servizio, anche se il containerPort viene fatto riferimento da un targetPort del servizio. Non sei limitato a containerPorts a cui fa riferimento il targetPort di un servizio.
  • HOST: il valore dell'intestazione host nella richiesta di controllo di integrità. Questo valore utilizza la definizione di nome host della RFC 1123 , ad eccezione degli indirizzi IP numerici, che non sono consentiti. Se non specificato o lasciato vuoto, questo valore viene impostato per impostazione predefinita sull'indirizzo IP del controllo di integrità.
  • REQUEST: specifica i dati dell'applicazione da inviare dopo che è stata stabilita la connessione TCP. Se non specificato, il valore predefinito è vuoto. Se sia la richiesta che la risposta sono vuote, la connessione stabilita da sola indica l'integrità. I dati della richiesta possono essere solo in formato ASCII.
  • REQUEST_PATH: specifica il request-path della richiesta di controllo di integrità. Se non specificato o lasciato vuoto, il valore predefinito è /.
  • RESPONSE: specifica i byte da confrontare con l'inizio dei dati di risposta. Se non specificato o lasciato vuoto, GKE interpreta qualsiasi risposta come integra. I dati di risposta possono essere solo ASCII.
  • PROXY_HEADER: specifica il tipo di intestazione proxy. Puoi utilizzare NONE o PROXY_V1. Il valore predefinito è NONE.
  • GRPC_SERVICE_NAME: un nome facoltativo del servizio gRPC. Ometti questo campo per specificare tutti i servizi.

Per saperne di più sui campi HealthCheckPolicy, consulta il healthChecks riferimento.

Configura la policy di sicurezza del backend di Cloud Armor per proteggere i servizi di backend

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Configura la policy di sicurezza del backend di Cloud Armor aggiungendo il nome della tua policy di sicurezza a GCPBackendPolicy per proteggere i servizi di backend. Per impostazione predefinita, il gateway non ha alcuna policy di sicurezza del backend Cloud Armor definita e collegata.

Assicurati di creare una policy di sicurezza del backend di Cloud Armor prima di fare riferimento alla policy in GCPBackendPolicy. Se stai attivando un gateway regionale, devi creare una policy di sicurezza del backend Cloud Armor regionale.

Il seguente manifest GCPBackendPolicy specifica una policy di sicurezza del backend denominata example-security-policy:

Servizio

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

Servizio multi-cluster

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

Configura IAP

Identity-Aware Proxy (IAP) applica le norme di controllo dell'accesso ai servizi di backend associati a una HTTPRoute. Con questa applicazione, solo gli utenti o le applicazioni autenticati con il ruolo Identity and Access Management (IAM) corretto assegnato possono accedere a questi servizi di backend.

Per impostazione predefinita, non viene applicato IAP ai tuoi servizi di backend. Devi configurare esplicitamente IAP in un GCPBackendPolicy.

Per configurare IAP con Gateway:

  1. Ottieni l'ID client e il client secret per il tuo client OAuth. Il client secret è disponibile solo quando crei il client OAuth. Per saperne di più, vedi Gestire i client OAuth.

  2. Abilita IAP per GKE.

    Non è necessario creare un BackendConfig, perché BackendConfig è una risorsa di configurazione Ingress.

  3. Per specificare i criteri IAP che fanno riferimento a un secret:

    1. Salva il seguente manifest GCPBackendPolicy come backend-policy.yaml:

      Servizio

      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

      Sostituisci quanto segue:

      • CLIENT_SECRET: il client secret OAuth.
      • CLIENT_ID: l'ID client OAuth.
      • SERVICE_NAME: il nome del servizio da targetizzare in GCPBackendPolicy.

      Servizio multi-cluster

      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

      Sostituisci quanto segue:

      • CLIENT_SECRET: il client secret OAuth.
      • CLIENT_ID: l'ID client OAuth.
      • SERVICEIMPORT_NAME: il nome di ServiceImport da scegliere come target in GCPBackendPolicy.

    2. Applica il manifest backend-policy.yaml:

      kubectl apply -f backend-policy.yaml

  4. Verifica la configurazione:

    1. Verifica che la policy sia stata applicata dopo aver creato GCPBackendPolicy con IAP:

      kubectl get gcpbackendpolicy

      L'output è simile al seguente:

      NAME             AGE
backend-policy   45m

    2. Per ulteriori dettagli, utilizza il comando describe:

      kubectl describe gcpbackendpolicy

      L'output è simile al seguente:

      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

Configura il timeout del servizio di backend

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Il seguente manifest GCPBackendPolicy specifica un periodo di timeout del servizio di backend di 40 secondi. Il campo timeoutSec è impostato su 30 secondi per impostazione predefinita.

Servizio

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

Servizio multi-cluster

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

Configura la selezione del backend utilizzando GCPBackendPolicy

La modalità di bilanciamento CUSTOM_METRICS all'interno di GCPBackendPolicy consente di configurare metriche personalizzate specifiche che influenzano il modo in cui i servizi di backend dei bilanciatori del carico distribuiscono il traffico. Questa modalità di bilanciamento consente di bilanciare il carico in base a metriche personalizzate definite e segnalate dai backend dell'applicazione.

Per saperne di più, consulta Gestione del traffico con bilanciamento del carico basato su metriche personalizzate.

L'array customMetrics[], nel campo backends[], contiene i seguenti campi:

  • name: specifica il nome definito dall'utente della metrica personalizzata.
  • maxUtilization: imposta l'utilizzo target o massimo per questa metrica. L'intervallo valido è [0, 100].
  • dryRun: un campo booleano. Se è true, i dati delle metriche vengono inviati a Cloud Monitoring, ma non influiscono sulle decisioni di bilanciamento del carico.

Esempio

L'esempio seguente mostra un manifest GCPBackendPolicy che configura metriche personalizzate per la selezione del backend e il routing a livello di endpoint.

  1. Salva il seguente manifest come 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. Applica il manifest al tuo cluster:

    kubectl apply -f my-backend-policy.yaml

Il bilanciatore del carico distribuisce il traffico in base alla modalità di bilanciamento RATE e alla metrica personalizzata gpu-load.

Configura il routing a livello di endpoint con GCPTrafficDistributionPolicy

L'API GCPTrafficDistributionPolicy in Google Kubernetes Engine (GKE) Gateway fornisce funzionalità avanzate di gestione del traffico che consentono un controllo preciso su come il traffico viene distribuito ai pod dell'applicazione. Questa risorsa unificata e nativa di GKE semplifica la gestione degli algoritmi di bilanciamento del carico e delle impostazioni di affinità sessione.

GCPTrafficDistributionPolicy ti consente di configurare:

  • Algoritmi di bilanciamento del carico: specifica come viene distribuito il traffico tra gli endpoint all'interno di un backend.

    • WEIGHTED_ROUND_ROBIN: quando selezioni questo algoritmo, il bilanciamento del carico utilizza metriche personalizzate per calcolare i pesi e distribuire il traffico in base a queste metriche riportate. L'array customMetrics[] all'interno della configurazione GCPTrafficDistributionPolicy include i seguenti campi:

      • name: specifica il nome definito dall'utente della metrica personalizzata.
      • dryRun: quando true, i dati delle metriche vengono segnalati a Cloud Monitoring, ma non influiscono sul bilanciamento del carico.

  • RING_HASH: questo algoritmo è utile per i servizi sensibili alle prestazioni della cache. Utilizza l'hashing coerente per ridurre al minimo la rimappatura delle richieste quando vengono aggiunti o rimossi pod di backend, il che contribuisce a garantire la stabilità durante gli eventi di scalabilità. La configurazione del campo minimumHashRingSize fornisce una distribuzione del carico più granulare.

  • Affinità sessione: contribuisce a garantire che le richieste dello stesso client vengano instradate in modo coerente allo stesso pod di backend. Questo è fondamentale per i workload stateful, come i carrelli degli acquisti di e-commerce o le sessioni di gioco. GKE Gateway utilizza GCPTrafficDistributionPolicy per supportare tutti i tipi di affinità sessione disponibili sulle Google Cloudistanze del bilanciatore del carico delle applicazioni, tra cui STRONG_COOKIE_AFFINITY, HEADER_FIELD, HTTP_COOKIE, GENERATED_COOKIE e CLIENT_IP.

Per saperne di più, consulta Gestione del traffico con bilanciamento del carico basato su metriche personalizzate.

Esempio

Il seguente esempio mostra un manifest GCPTrafficDistributionPolicy che configura il routing a livello di endpoint utilizzando sia l'algoritmo di bilanciamento del carico WEIGHTED_ROUND_ROBIN sia le metriche personalizzate.

  1. Salva il seguente manifest di esempio come 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. Applica il manifest al tuo cluster:

    kubectl apply -f GCPTrafficDistributionPolicy.yaml

Il bilanciatore del carico distribuisce il traffico agli endpoint in base all'algoritmo WEIGHTED_ROUND_ROBIN e alle metriche personalizzate fornite.

Configurare le dimensioni dell'anello hash

Per i servizi in cui ridurre al minimo gli errori della cache è fondamentale, utilizza l'algoritmo RING_HASH. La modifica del campo minimumHashRingSize consente una distribuzione del carico più granulare tra i backend. Sebbene il bilanciatore del carico gestisca automaticamente le dimensioni dell'anello, fornire un valore minimo più elevato può contribuire a garantire una distribuzione più uniforme delle richieste per set di backend più grandi.

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

Configura l'affinità sessione

Configura l'affinità sessione per assicurarti che le richieste dello stesso client vengano indirizzate in modo coerente allo stesso pod di backend.

Configura l'affinità sessione utilizzando GCPTrafficDistributionPolicy (impostazione predefinita)

I tipi di affinità sessione descritti in questa sezione richiedono le seguenti versioni minime di GKE:

  • CLIENT_IP, HEADER_FIELD, GENERATED_COOKIE e HTTP_COOKIE: versione 1.35.2-gke.1269001 o successive.
  • STRONG_COOKIE_AFFINITY:versione 1.36.3-gke.1767000 o successive.

GKE Gateway supporta tutti i tipi di affinità sessione utilizzando la risorsa GCPTrafficDistributionPolicy. Questa risorsa fornisce un controllo più granulare, ad esempio il routing basato su intestazioni HTTP o cookie personalizzati. La configurazione dell'affinità sessione utilizzando GCPTrafficDistributionPolicy è il metodo predefinito e consigliato.

La tabella seguente descrive i tipi di affinità supportati quando utilizzi GCPTrafficDistributionPolicy:

Tipo di affinità Descrizione
STRONG_COOKIE_AFFINITY Persistenza della sessione basata sui cookie stateful. Consente di garantire una forte permanenza della sessione durante gli eventi di scalabilità e i ridimensionamenti del pool di pod. Devi configurare il campo cookie.name e, facoltativamente, puoi configurare i campi cookie.path e cookie.ttl. Funziona con qualsiasi impostazione di localityLbAlgorithm (il valore predefinito è ROUND_ROBIN).
HTTP_COOKIE Affinità basata su un cookie HTTP. Quando risponde alla prima richiesta, il bilanciatore del carico genera un cookie e lo fornisce in un'intestazione della risposta Set-Cookie. Nelle richieste successive, il client restituisce il cookie fornito dal bilanciatore del carico e il bilanciatore del carico lo utilizza per instradare le richieste in modo coerente agli stessi pod. Devi configurare il campo cookie.name e, se vuoi, puoi configurare i campi cookie.path e cookie.ttl. Richiede che il campo localityLbAlgorithm sia impostato su MAGLEV o RING_HASH.
GENERATED_COOKIE Il bilanciatore del carico genera un cookie per monitorare la sessione. Il nome del cookie è GCLB per i bilanciatori del carico delle applicazioni esterni globali e GCILB per i bilanciatori del carico delle applicazioni interni regionali e i bilanciatori del carico delle applicazioni esterni regionali. Il percorso del cookie è /. Se vuoi, puoi configurare il campo cookie.ttl fino a un massimo di due settimane; i campi cookie.name e cookie.path non sono configurabili per questo tipo. Richiede che il campo localityLbAlgorithm sia impostato su MAGLEV o RING_HASH.
HEADER_FIELD Affinità basata su un'intestazione HTTP specifica. Richiede che il campo localityLbAlgorithm sia impostato su MAGLEV o RING_HASH.
CLIENT_IP Affinità basata sull'indirizzo IP del client. Richiede che il campo localityLbAlgorithm sia impostato su MAGLEV o RING_HASH.
NONE Disattiva l'affinità sessione.

Gli esempi seguenti mostrano come configurare GCPTrafficDistributionPolicy raggruppata per categoria di affinità: basata sui cookie, sull'intestazione e sull'affinità sessione basata sull'IP client.

Per applicare una delle seguenti configurazioni di affinità sessione al cluster, procedi nel seguente modo:

  1. Salva il manifest scelto come policy.yaml.

  2. Applica il manifest al tuo cluster:

    kubectl apply -f policy.yaml

L'affinità sessione basata sui cookie include i tipi di affinità STRONG_COOKIE_AFFINITY, HTTP_COOKIE e GENERATED_COOKIE.

Affinità dei cookie con stato (STRONG_COOKIE_AFFINITY)

L'affinità cookie stateful (STRONG_COOKIE_AFFINITY) fornisce la persistenza della sessione stateful che mantiene l'affinità anche durante gli eventi di scalabilità del backend.

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

Affinità dei cookie HTTP (HTTP_COOKIE)

Il tipo di affinità HTTP_COOKIE si basa su un cookie denominato specifico restituito in un'intestazione Set-Cookie. Per utilizzare tipi di affinità sessione diversi da NONE e STRONG_COOKIE_AFFINITY, devi impostare il campo localityLbAlgorithm su MAGLEV o RING_HASH.

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

Affinità dei cookie generata (GENERATED_COOKIE)

Il tipo di affinità GENERATED_COOKIE consente al bilanciatore del carico di generare e denominare automaticamente il cookie di sessione. Se vuoi, puoi configurare il valore del campo cookie.ttl fino a due settimane (336h).

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

Il comportamento del TTL pari a zero per l'affinità sessione basata sui cookie include quanto segue:

  • Tutte le affinità sessione basate sui cookie (STRONG_COOKIE_AFFINITY, HTTP_COOKIE e GENERATED_COOKIE) hanno un attributo ttl.

  • Un TTL di zero secondi indica che il bilanciatore del carico non assegna un attributo Expires al cookie. In questo caso, il client considera il cookie come un cookie di sessione. La definizione di sessione varia a seconda del client:

    • Alcuni client, come i browser web, conservano il cookie per l'intera sessione di navigazione. Questo approccio significa che il cookie persiste in più richieste finché l'applicazione non viene chiusa.
    • Altri client trattano una sessione come una singola richiesta HTTP, eliminando il cookie immediatamente dopo la fine della sessione.

Affinità sessione basata sull'intestazione

Il tipo di affinità HEADER_FIELD instrada il traffico in base a un'intestazione HTTP specifica per scenari come i test A/B o il routing client specializzato in cui un cookie non è adatto. Per utilizzare tipi di affinità sessione diversi da NONE e STRONG_COOKIE_AFFINITY, devi impostare il campo localityLbAlgorithm su MAGLEV o RING_HASH. A differenza dell'ROUND_ROBIN predefinito, questi algoritmi supportano l'hashing coerente basato su campi personalizzati come le intestazioni HTTP.

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

Affinità sessione basata sull'indirizzo IP client

Il tipo di affinità CLIENT_IP indirizza il traffico da un indirizzo IP client specifico allo stesso pod di backend nel miglior modo possibile. Per utilizzare tipi di affinità sessione diversi da NONE e STRONG_COOKIE_AFFINITY, devi impostare il campo localityLbAlgorithm su MAGLEV o RING_HASH.

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

Verifica la policy

Per assicurarti che GCPTrafficDistributionPolicy sia configurata correttamente e attiva, verifica il suo stato dopo averla applicata:

  1. Per controllare lo stato della policy, esegui questo comando:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Sostituisci POLICY_NAME con il nome della tua policy.

  2. Nell'output, controlla la sezione Conditions. Uno stato True con il motivo Attached indica che la configurazione è valida e attiva.

Configura l'affinità sessione utilizzando GCPBackendPolicy

Questa sezione descrive la configurazione dell'affinità sessione utilizzando GCPBackendPolicy.

Puoi configurare l'affinità sessione di GCPBackendPolicy in base ai seguenti criteri:

  • Indirizzo IP client (CLIENT_IP)
  • Cookie generato (GENERATED_COOKIE)

Quando configuri l'affinità sessione per il tuo servizio utilizzando GCPBackendPolicy, il gateway imposta l'impostazione localityLbPolicy sul servizio di backend su MAGLEV. Quando rimuovi l&#39affinità sessionee da GCPBackendPolicy, il gateway ripristina l'impostazione localityLbPolicy al valore predefinito, ROUND_ROBIN.

Il seguente manifest GCPBackendPolicy specifica l'affinità sessione in base all'indirizzo IP client:

Servizio

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

Servizio multi-cluster

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

Il seguente manifest GCPBackendPolicy specifica l'affinità sessione in base a un cookie generato e configura il TTL del cookie su 50 secondi:

Servizio

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

Servizio multi-cluster

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

Configurare il timeout per lo svuotamento della connessione

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Puoi configurare il timeout di svuotamento della connessione utilizzando GCPBackendPolicy. Il timeout per lo svuotamento della connessione è il tempo, in secondi, di attesa per lo svuotamento delle connessioni. La durata del timeout può essere compresa tra 0 e 3600 secondi. Il valore predefinito è 0, che disabilita anche lo svuotamento della connessione.

Il seguente manifest GCPBackendPolicy specifica un timeout per svuotamento della connessione di 60 secondi:

Servizio

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

Servizio multi-cluster

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

Per la durata specificata del timeout, GKE attende il completamento delle richieste esistenti al backend rimosso. Il bilanciatore del carico non invia nuove richieste al backend rimosso. Una volta raggiunto il periodo di timeout, GKE chiude tutte le connessioni rimanenti al backend.

Registrazione dell'accesso HTTP

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la versione 1.24 o successive.

Per impostazione predefinita:

  • Il controller del gateway registra tutte le richieste HTTP dai client in Cloud Logging.
  • La frequenza di campionamento è 1.000.000, il che significa che tutte le richieste vengono registrate.
  • Non sono registrati campi facoltativi.

Puoi disattivare il logging degli accessi sul gateway utilizzando un GCPBackendPolicy in tre modi:

  • Puoi lasciare GCPBackendPolicy senza la sezione logging
  • Puoi impostare logging.enabled su false
  • Puoi impostare logging.enabled su true e logging.sampleRate su 0

Puoi anche configurare la frequenza di campionamento della registrazione degli accessi e un elenco di campi facoltativi, ad esempio tls.cipher o orcaLoadReport.

Per attivare il logging dei campi facoltativi:

  • Imposta logging.OptionalMode su CUSTOM.
  • Fornisci l'elenco dei campi facoltativi da registrare nel log in logging.optionalFields. Consulta la sezione Registrazione e monitoraggio per l'elenco dei campi supportati.

Puoi disattivare la registrazione dei campi facoltativi in due modi:

  • Puoi rimuovere tutte le voci da logging.optionalFields.
  • Puoi impostare logging.OptionalMode su EXCLUDE_ALL_OPTIONAL.

Il seguente manifest GCPBackendPolicy modifica la frequenza di campionamento predefinita della registrazione degli accessi e la imposta sul 50% delle richieste HTTP. Il manifest consente anche la registrazione di due campi facoltativi per una determinata risorsa di servizio:

Servizio

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

Servizio multi-cluster

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

Questo manifest contiene i seguenti campi:

  • enable: true: abilita esplicitamente la registrazione degli accessi. I log sono disponibili in Logging.
  • sampleRate: 500000: specifica che viene registrato il 50% dei pacchetti. Puoi utilizzare un valore compreso tra 0 e 1.000.000. GKE converte questo valore in un valore in virgola mobile compreso nell'intervallo [0, 1] dividendolo per 1.000.000. Questo campo è pertinente solo se enable è impostato su true. sampleRate è un campo facoltativo, ma se è configurato, deve essere impostato anche enable: true. Se enable è impostato su true e sampleRate non viene fornito, GKE imposta enable su false.
  • optionalMode: CUSTOM: specifica che un insieme di optionalFields deve essere incluso nelle voci di log.
  • optionalFields: tls.cipher, orcaLoadReport.cpu_utilization: specifica che le voci di log devono includere sia il nome della crittografia utilizzata per l'handshake TLS sia l'utilizzo della CPU del servizio, se disponibili.

Configura la scalabilità automatica basata sul traffico per il gateway a cluster singolo

Assicurati che il cluster GKE esegua la versione 1.31.1-gke.2008000 o successive.

Per abilitare la scalabilità automatica basata sul traffico e il bilanciamento del carico basato sulla capacità in un gateway a cluster singolo, puoi configurare la capacità del servizio. La capacità del servizio è la possibilità di specificare la quantità di capacità di traffico che un servizio può ricevere prima che i pod vengano scalati automaticamente o che il traffico venga trasferito ad altri cluster disponibili.

Per configurare la capacità del servizio, crea un servizio e una GCPBackendPolicy associata. Il manifest GCPBackendPolicy utilizza il campo maxRatePerEndpoint che definisce un valore massimo di richieste al secondo (RPS) per pod in un servizio. Il seguente manifest GCPBackendPolicy definisce un RPS massimo di 10:

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

Per saperne di più sulla scalabilità automatica basata sul traffico, consulta Scalabilità automatica basata sul traffico del bilanciamento del carico.

Risoluzione dei problemi

Questa sezione fornisce indicazioni per la risoluzione dei problemi comuni durante la configurazione delle risorse Gateway utilizzando i criteri.

GCPTrafficDistributionPolicy non ha effetto

Sintomo: il traffico non viene distribuito in base all'affinità sessione o alle impostazioni di località definite nel criterio.

Motivo:in genere si verifica se il criterio non è associato correttamente al servizio o se il controller gateway ha rilevato un errore di convalida durante il tentativo di sincronizzazione della configurazione con il bilanciatore del carico.

Soluzione temporanea:

  1. Verifica lo stato della policy: controlla se la policy è stata collegata al tuo servizio:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Sostituisci POLICY_NAME con il nome della tua policy.

    Nell'output, cerca la sezione Conditions. Lo stato True con il motivo Attached indica che la configurazione è valida ed è stata applicata. Se lo stato è False, controlla i campi Reason e Message per verificare la presenza di errori di convalida (ad esempio, un algoritmo non supportato per il tipo di affinità scelto).

  2. Verifica la sincronizzazione della configurazione del gateway: conferma che il gateway che gestisce il traffico abbia sincronizzato correttamente queste impostazioni con l'infrastruttura cloud.

    Nella sezione Status, verifica che la condizione Programmed abbia un Status di True. Se è False, indica che il controller Gateway ha riscontrato un errore, potenzialmente correlato a GCPTrafficDistributionPolicy.

    Controlla i campi Reason e Message accanto alla condizione Programmed per i dettagli immediati. Per messaggi di errore più granulari o una cronologia degli errori di sincronizzazione, controlla Events nella parte inferiore dell'output.

Più GCPBackendPolicy collegate allo stesso servizio

Sintomo:

La seguente condizione di stato potrebbe verificarsi quando colleghi un GCPBackendPolicy a un servizio o a un ServiceImport:

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

Motivo:

Questa condizione di stato indica che stai tentando di applicare una seconda GCPBackendPolicy a un servizio o a un ServiceImport a cui è già associata una GCPBackendPolicy.

Più GCPBackendPolicy collegate allo stesso servizio o ServiceImport non sono supportate con GKE Gateway. Per ulteriori dettagli, consulta la sezione Restrizioni e limitazioni.

Soluzione temporanea:

Configura un'unica GCPBackendPolicy che includa tutte le configurazioni personalizzate e collegala alla risorsa di destinazione (Service, ServiceImport, InferencePool o GCPInferencePoolImport).

Affinità sessione ignorata durante la suddivisione del traffico

Sintomo:

Le richieste non vengono instradate in modo coerente allo stesso pod di backend anche se è configurata l'affinità sessione.

Motivo:

La suddivisione del traffico ponderata ha la precedenza sull'affinità sessione. Se una HTTPRoute definisce i pesi per più backend, il bilanciatore del carico seleziona prima un backend in base ai pesi prima di applicare la logica di affinità.

Soluzione temporanea:

Evita di utilizzare la suddivisione del traffico ponderata nella stessa regola HTTPRoute in cui è richiesta la persistenza della sessione.

Criterio di sicurezza di Cloud Armor non trovato

Sintomo:

Quando abiliti Cloud Armor sul gateway regionale, potrebbe essere visualizzato il seguente messaggio di errore:

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

Motivo:

Il messaggio di errore indica che la policy di sicurezza regionale di Cloud Armor specificata non esiste nel tuo progetto Google Cloud .

Soluzione temporanea:

Crea una policy di sicurezza di Cloud Armor regionale nel tuo progetto e fai riferimento a questa policy in GCPBackendPolicy.

Passaggi successivi