Configura le risorse di 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 del 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, non è necessario eliminare o ricreare le risorse Gateway, Route o Service. Il criterio viene elaborato dal controller del gateway e la risorsa di bilanciamento del carico sottostante viene (ri)configurata in base al (nuovo) criterio.

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
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le località predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Requisiti del controller GKE Gateway

• Per Standard, GKE 1.24 o versioni successive.
• Per Autopilot, GKE versione 1.26 o successive.
• Google Cloud CLI versione 407.0.0 o successive.
• L'API Gateway è supportata solo sui cluster VPC nativi.
• Se utilizzi GatewayClasses interni, devi abilitare 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 restrizioni del controller GKE Gateway, si applicano le seguenti limitazioni specifiche ai criteri applicati alle risorse Gateway:

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

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

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

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

• Può essere collegato un solo GCPBackendPolicy a un servizio alla volta. Quando vengono create due norme GCPBackendPolicy che hanno come target lo stesso Service o ServiceImport, la norma più vecchia ha la precedenza e la seconda non viene allegata.

• Le policy gerarchiche non sono supportate con GKE Gateway.

• HealthCheckPolicy e GCPBackendPolicy devono esistere nello stesso spazio dei nomi della risorsa target Service o ServiceImport.

• 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&#39affinità sessionee.

Configurare l'accesso globale per il gateway interno regionale

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

Per abilitare l'accesso globale con il tuo gateway interno, collega un criterio 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:
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Nota :l'upgrade di un gateway interno esistente mediante l'aggiunta dell'accesso globale ricrea la regola di forwarding del bilanciatore del carico interno regionale. Questo upgrade elimina e poi ricrea Google Cloud i bilanciatori del carico, il che comporta fino a 15 minuti di indisponibilità. Ti consigliamo di eseguire questa operazione durante un periodo di manutenzione per evitare tempi di inattività dell'applicazione.

Configura la regione per il gateway multi-cluster

Questa sezione descrive una funzionalità disponibile sui cluster GKE che eseguono la 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 del 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 multicluster, 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

Nota: se aggiorni la regione in un gateway multicluster regionale esistente, il bilanciatore del carico sottostante viene eliminato nella vecchia regione e ricreato nella nuova regione.

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

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

Per proteggere il traffico dal client al bilanciatore del carico, configura il criterio SSL aggiungendo il nome del criterio a GCPGatewayPolicy. Per impostazione predefinita, il gateway non ha criteri SSL definiti e collegati.

Assicurati di creare una policy SSL prima di farvi riferimento nel tuo GCPGatewayPolicy.

Nota: se utilizzi un gateway regionale, assicurati di creare una policy SSL regionale.

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 nei 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 e http2) 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 HealthCheckPolicy personalizzato per il bilanciatore del carico se il percorso del controllo di integrità non è "/" 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 quel percorso di richiesta e utilizza invece "/health" per segnalare il suo stato, devi configurare requestPath nel tuo HealthCheckPolicy di conseguenza.

Nota: per consentire al controller del gateway di elaborare i controlli di integrità e aggiornare i parametri, il servizio definito nella policy di controllo di integrità deve essere referenziato anche nel manifest HTTPRoute.

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

Servizio

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

Servizio multi-cluster

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

Sostituisci quanto segue:

• INTERVAL: specifica l'intervallo di controllo, in secondi, per ogni sonda di controllo di integrità. Questo è il tempo che intercorre tra l'inizio del controllo di un probe e l'inizio del controllo successivo. Se ometti questo parametro, il valore predefinito di Google Cloud è 15 secondi se non è specificato alcun HealthCheckPolicy ed è 5 secondi quando viene specificato un HealthCheckPolicy senza valore checkIntervalSec. Per ulteriori informazioni, vedi 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. Le unità sono in secondi. Ogni probe richiede la restituzione di un codice di risposta HTTP 200 (OK) prima del timeout del probe.
• HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: specifica il numero di tentativi di connessione sequenziali che devono riuscire o non riuscire, per almeno un prober, 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 e Criteri di esito positivo per gRPC. 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 utilizzata (USE_SERVING_PORT). Se non specificato, il controllo di integrità segue il comportamento specificato nei campi port e portName. Se non vengono specificati port o portName, questo campo viene impostato su USE_SERVING_PORT per impostazione predefinita.
• 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.
• PORT_NAME: specifica il nome della porta come definito in InstanceGroup.NamedPort.name. Se sono definiti sia port che portName, Google Cloud considera prima il valore di port.
• 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_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 ulteriori informazioni sui campi HealthCheckPolicy, consulta il healthChecks riferimento.

Configura i criteri di sicurezza del backend Google Cloud Armor per proteggere i tuoi servizi di backend

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

Nota: Google Cloud ha sostituito le norme LbPolicy con le norme GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

Configura la policy di sicurezza del backend di Google Cloud Armor aggiungendo il nome della tua policy di sicurezza a GCPBackendPolicy per proteggere i tuoi servizi di backend. Per impostazione predefinita, il gateway non ha definito e collegato alcun criterio di sicurezza del backend di Google Cloud Armor.

Assicurati di creare un criterio di sicurezza di backend di Google Cloud Armor prima di fare riferimento al criterio nel tuo GCPBackendPolicy. Se abiliti un gateway regionale, devi creare un criterio di sicurezza di backend regionale di Google Cloud Armor.

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:
    securityPolicy: example-security-policy
  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:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Configura IAP

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

Identity-Aware Proxy (IAP) applica i criteri 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 applicata alcuna IAP ai tuoi servizi di backend. Devi configurare esplicitamente IAP in un GCPBackendPolicy.

Per configurare IAP con Gateway:

1. Abilita IAP per GKE Non configurare il backend (Configurazione di BackendConfig) perché BackendConfig è valido solo nel caso di un deployment Ingress.

2. Crea un secret per IAP:

   1. Nella console Google Cloud , vai alla pagina Credenziali:

      Vai a credenziali

   2. Fai clic sul nome del client e scarica il file client OAuth.

   3. Dal file client OAuth, copia il segreto OAuth negli appunti.

   4. Crea un file denominato iap-secret.txt.

   5. Incolla il segreto OAuth nel file iap-secret.txt utilizzando il seguente comando:

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

3. Per specificare un criterio IAP che fa riferimento a un secret:

   1. Crea il seguente manifest GCPBackendPolicy, sostituisci SECRET_NAME e CLIENT_ID rispettivamente. Salva il manifest come backend-policy.yaml:

      Servizio

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

      Servizio multi-cluster

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

   2. Applica il manifest backend-policy.yaml:

      kubectl apply -f backend-policy.yaml
      

4. Verifica la configurazione:

   1. Verifica che il criterio sia stato applicato dopo aver creato il tuo GCPBackendPolicy con IAP:

      kubectl get gcpbackendpolicy
      

      L'output è simile al seguente:

      NAME             AGE
      backend-policy   45m
      

   2. Per ottenere maggiori 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 nei cluster GKE che eseguono la versione 1.24 o successive.

Nota: Google Cloud ha sostituito le norme LbPolicy con le norme GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

Il seguente file 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:
    timeoutSec: 40
  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
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Configura la selezione del backend utilizzando GCPBackendPolicy

La modalità di bilanciamento CUSTOM_METRICS all'interno di GCPBackendPolicy ti 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.

Nota: la modalità di bilanciamento CUSTOM_METRICS è disponibile solo su GKE versione 1.33 e successive.

Per ulteriori informazioni, vedi 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:
   targetRef:
     kind: Service
     name: super-service
   default:
     backends:
     - location: "*"
       balancingMode: RATE
       maxRatePerEndpoint: 9000
     - location: us-central1-a  # specific block applies to given zone / region only.
       # maxRatePerEndpoint: 9000 inherited from unnamed
       balancingMode: CUSTOM_METRICS
       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. Applica il manifest al 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

GCPTrafficDistributionPolicy configura l'algoritmo di bilanciamento del carico per la selezione degli endpoint all'interno di un backend. Quando selezioni WEIGHTED_ROUND_ROBIN, il bilanciatore del carico utilizza pesi derivati dalle metriche riportate (incluse le metriche personalizzate) per distribuire il traffico alle singole istanze o ai singoli endpoint.

Il campo WEIGHTED_ROUND_ROBIN localityLbPolicy della risorsa GCPTrafficDistributionPolicy specifica un algoritmo di bilanciamento del carico per selezionare singole istanze o endpoint all'interno di un backend. Quando utilizzi questo algoritmo, il criterio utilizza metriche personalizzate per calcolare i pesi per l'assegnazione del carico.

L'array customMetrics[] all'interno della configurazione GCPTrafficDistributionPolicy contiene i seguenti campi:

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

Nota: le metriche personalizzate definite in GCPTrafficDistributionPolicy si applicano solo a WEIGHTED_ROUND_ROBIN localityLbPolicy e non vengono ereditate da backends[].customMetrics[] in GCPBackendPolicy.

Per ulteriori informazioni, vedi Gestione del traffico con bilanciamento del carico basato su metriche personalizzate.

Esempio

L'esempio seguente 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:
     - kind: Service
       group: ""
       name: echoserver-v2
     default:
       localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
       customMetrics:
       - name: orca.named_metrics.bescm11
         dryRun: false
       - name: orca.named_metrics.bescm12
         dryRun: true
   

2. Applica il manifest al cluster:

   kubectl apply -f GCPTrafficDistributionPolicy.yaml
   

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

Configura l'affinità sessione

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

Nota: Google Cloud ha sostituito le norme LbPolicy con le norme GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

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

• Indirizzo IP client
• Cookie generato

Quando configuri l'affinità di sessione per il tuo servizio, l'impostazione localityLbPolicy del gateway viene impostata su MAGLEV.

Quando rimuovi una configurazione di affinità sessione da GCPBackendPolicy, il gateway ripristina l'impostazione localityLbPolicy al valore predefinito, ROUND_ROBIN.

Avviso: questo valore viene impostato automaticamente sul servizio di backend gestito da GKE (collegato al bilanciatore del carico) e non viene visualizzato nell'output di un comando gcloud CLI, nell'interfaccia utente o con Terraform.

Il seguente manifest GCPBackendPolicy specifica un'affinità sessione basata sull'indirizzo IP client:

Servizio

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

Servizio multi-cluster

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

Il seguente manifest GCPBackendPolicy specifica un'affinità sessione basata su un cookie generato e configura il TTL dei cookie su 50 secondi:

Servizio

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

Servizio multi-cluster

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

Puoi utilizzare i seguenti valori per il campo sessionAffinity.type:

• CLIENT_IP
• GENERATED_COOKIE
• NONE

Configurare il timeout per lo svuotamento della connessione

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

Nota: Google Cloud ha sostituito le norme LbPolicy con le norme GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

Puoi configurare il timeout per lo 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

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. Al termine del periodo di timeout, GKE chiude tutte le connessioni rimanenti al backend.

Registrazione dei log di accesso HTTP

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

Nota: Google Cloud ha sostituito le norme LbPolicy con le norme GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

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.
• Nessun campo facoltativo viene registrato.

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

• Puoi lasciare la sezione GCPBackendPolicy senza 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 "orca_load_report".

Per attivare il logging dei campi facoltativi:

• Imposta logging.OptionalMode su CUSTOM.
• Fornisci l'elenco dei campi facoltativi da registrare in logging.optionalFields. Consulta Logging 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 Service:

Servizio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.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:
    logging:
      enabled: true
      sampleRate: 500000
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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 viene configurato, deve essere impostato anche enable: true. Se enable è impostato su true e sampleRate non viene fornito, allora GKE imposta enable su false.
• optionalMode: CUSTOM: specifica che un insieme di optionalFields deve essere incluso nelle voci di log.
• optionalFields: tls.cipher, orca_load_report.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.

Configurare 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 un GCPBackendPolicy associato. Il manifest GCPBackendPolicy utilizza il campo maxRatePerEndpoint che definisce un valore massimo di richieste al secondo (RPS) per pod in un servizio. Il seguente file 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 scoprire di più sulla scalabilità automatica basata sul traffico, consulta Scalabilità automatica basata sul traffico del bilanciatore del carico.

Risoluzione dei problemi

Più GCPBackendPolicy allegati allo stesso Service

Sintomo:

La seguente condizione di stato potrebbe verificarsi quando colleghi un GCPBackendPolicy a un Service 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 un secondo GCPBackendPolicy a un Service o ServiceImport a cui è già associato un GCPBackendPolicy.

Più GCPBackendPolicy collegati allo stesso Service o ServiceImport non sono supportati con GKE Gateway. Per ulteriori dettagli, consulta la sezione Limitazioni.

Soluzione:

Configura un singolo GCPBackendPolicy che includa tutte le configurazioni personalizzate e allegalo al tuo Service o ServiceImport.

Criterio di sicurezza di Google Cloud Armor non trovato

Sintomo:

Quando abiliti Google Cloud Armor sul tuo 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 Google Cloud Armor specificata non esiste nel tuo progetto Google Cloud .

Soluzione:

Crea un criterio di sicurezza di Google Cloud Armor regionale nel tuo progetto e fai riferimento a questo criterio nel tuo GCPBackendPolicy.

Passaggi successivi

• Scopri di più sul controller del gateway.
• Scopri come fare riferimento a un gateway da una risorsa.
• Visualizza il riferimento API Policy Types.
• Visualizza le definizioni dei tipi di API.