Configura le risorse di Gateway utilizzando i criteri

Questa pagina mostra come configurare il bilanciatore del carico creato da Google Kubernetes Engine (GKE) 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 viene creato da GKE. Questo bilanciatore del carico gestito è preconfigurato con impostazioni predefinite che puoi modificare utilizzando un criterio.

Puoi personalizzare le risorse di Gateway in base ai requisiti dell'infrastruttura o dell'applicazione collegando i criteri a gateway, servizi o importazioni di servizi. Dopo aver applicato o modificato un criterio, non è necessario eliminare o rielaborare le risorse gateway, route o servizio. Il criterio viene elaborato dal controller gateway e la risorsa bilanciatore 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Requisiti di GKE Gateway Controller

  • 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 su cluster VPC-native.
  • Se utilizzi GatewayClasses interno, devi attivare una subnet solo proxy.
  • Nel cluster deve essere attivato il componente aggiuntivo HttpLoadBalancing.
  • 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 all'account di servizio GKE per il progetto di servizio.

Restrizioni e limitazioni

Oltre alle limitazioni e restrizioni del controller GKE Gateway, le seguenti limitazioni si applicano specificamente ai criteri applicati alle risorse Gateway:

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

  • Le risorse GCPGatewayPolicy devono esistere nello stesso spazio dei nomi del targetGateway.

  • Quando utilizzi un singolo cluster, le risorse Gateway, 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.

  • È possibile collegare un solo GCPGatewayPolicy a un servizio alla volta. Quando vengono creati due criteri GCPGatewayPolicy che hanno come target lo stesso Service o ServiceImport, avrà la precedenza il criterio più vecchio e il secondo non verrà collegato.

  • I criteri gerarchici non sono supportati con GKE Gateway.

  • Le risorse HealthCheckPolicy e GCPBackendPolicy devono essere 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.

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, allega 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

Configura la regione per il gateway multi-cluster

Questa sezione descrive una funzionalità disponibile nei cluster GKE che eseguono la versione 1.30.3-gke.1225000 o successive.

Se il tuo parco risorse 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 implementare i 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 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 un criterio SSL prima di fare riferimento al criterio in GCPGatewayPolicy.

Il seguente manifest GCPGatewayPolicy specifica un criterio di sicurezza denominato 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

Configurare i controlli di integrità

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

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 stato univoco per ogni servizio di backend per ogni servizio GKE.

Affinché il bilanciatore del carico funzioni normalmente, potresti dover 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 della richiesta predefinito è "/", ma non è possibile accedere al servizio in quel percorso della richiesta e viene utilizzato "/health" per segnalarne lo stato, devi configurare requestPath in HealthCheckPolicy di conseguenza.

Il seguente manifest HealthCheckPolicy mostra tutti i campi disponibili durante la configurazione di un criterio di controllo di integrità'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 il valore check-interval, in secondi, per ogni prober del controllo di integrità. Si tratta del tempo che intercorre tra l'inizio del controllo di un sondatore e l'inizio del controllo successivo. Se ometti questo parametro, il valore predefinito di Google Cloud è 15 secondi se non è specificato HealthCheckPolicy e 5 secondi se è specificato HealthCheckPolicy senza valore checkIntervalSec. Per ulteriori informazioni, consulta Più sonde e frequenza.
  • TIMEOUT: specifica il tempo che Google Cloud attende una risposta a una sonda. Il valore di TIMEOUT deve essere minore o uguale a INTERVAL. Le unità di misura sono in secondi. Ogni prova richiede che venga inviato un codice di risposta HTTP 200 (OK) prima del timeout della prova.
  • 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 il stato di integrità da integro a non integro o da non integro a integro. Se ometti uno di questi parametri, il valore predefinito di Google Cloud è 2.
  • PROTOCOL: specifica un protocollo utilizzato dai sistemi di probe per il controllo di integrità. Per ulteriori informazioni, consulta Criteri di esito positivo per HTTP, HTTPS e HTTP/2 e Criteri di esito positivo per gRPC. Questo parametro è obbligatorio.
  • ENABLED: specifica se il logging è abilitato o disabilitato.
  • PORT_SPECIFICATION: specifica se il controllo di integrità utilizza una porta fissa (USE_FIXED_PORT), una porta denominata (USE_NAMED_PORT) o la porta in uso (USE_SERVING_PORT). Se non specificato, il controllo di integrità segue il comportamento specificato nei campi port e portName. Se non viene specificato né port né portName, il valore predefinito di questo campo è USE_SERVING_PORT.
  • PORT: un criterio HealthCheckPolicy supporta solo l'indicazione 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 direttamente i controlli all'indirizzo IP del pod, devi selezionare una porta corrispondente a un containerPort di un pod in esecuzione, anche se il containerPort è fatto riferimento da un targetPort del servizio. Non sei vincolato ai 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 prende in considerazione prima il valore port.
  • HOST: il valore dell'intestazione host nella richiesta di controllo dello stato. Questo valore utilizza la definizione di un nome host di RFC 1123 , ad eccezione del fatto che non sono consentiti indirizzi IP numerici. Se non specificato o lasciato vuoto, questo valore predefinito è l'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 sana. 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 la healthChecks documentazione di riferimento.

Configura il criterio di sicurezza del backend di Google Cloud Armor per proteggere i servizi di backend

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

Configura il criterio di sicurezza del backend di Google Cloud Armor aggiungendo il nome del criterio di sicurezza a GCPBackendPolicy per proteggere i servizi di backend. Per impostazione predefinita, il gateway non ha criteri di sicurezza di backend Google Cloud Armor definiti e associati.

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

Il seguente manifest GCPBackendPolicy specifica un criterio di sicurezza del backend chiamato 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

Configurare 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 un'route HTTP. Con questa applicazione, solo gli utenti o le applicazioni autenticati con il ruolo IAM (Identity and Access Management) corretto assegnato possono accedere a questi servizi di backend.

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

Per configurare IAP con Gateway:

  1. Attiva IAP per GKE Non configurare il backend (Configurazione di BackendConfig) perché BackendConfig è valido solo in caso di implementazione di Ingress.

  2. Crea un secret per l'IAP:

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

      Vai a credenziali

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

    3. Dal file del 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 il criterio IAP che fa riferimento a un secret:

    1. Crea il seguente file manifest GCPBackendPolicy, sostituisci rispettivamente SECRET_NAME e CLIENT_ID. 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 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 GCPGatewayPolicy "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.

Il seguente manifest GCPBackendPolicy specifica un periodo di timeout del servizio di backend di 40 secondi. Il valore predefinito del campo timeoutSec è 30 secondi.

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

Configurare l'affinità sessione

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

Puoi configurare la similarità di sessione in base ai seguenti criteri:

  • Indirizzo IP del client
  • Cookie generato

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

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

Il seguente manifest GCPBackendPolicy specifica un'affinità sessione in base all'indirizzo IP del 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

Configura il timeout per lo svuotamento della connessione

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

Puoi configurare il timeout per lo svuotamento della connessione utilizzando GCPBackendPolicy. Il timeout per lo svuotamento delle connessioni è il tempo, in secondi, di attesa per lo svuotamento delle connessioni. La durata del timeout può variare da 0 a 3600 secondi. Il valore predefinito è 0, che disattiva anche lo svuotamento della connessione.

Il seguente manifest GCPBackendPolicy specifica un timeout per lo 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. Una volta raggiunta la durata del timeout, GKE chiude tutte le connessioni rimanenti al backend.

Log degli accessi HTTP

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

Per impostazione predefinita:

  • Il controller di gateway registra tutte le richieste HTTP dei client in Cloud Logging.
  • La frequenza di campionamento è 1.000.000, il che significa che tutte le richieste vengono registrate.

Puoi disattivare il logging degli accessi sul tuo 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 del logging degli accessi.

Il seguente manifest GCPBackendPolicy modifica la frequenza di campionamento predefinita della registrazione degli accessi e la imposta sul 50% delle richieste HTTP 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:
    logging:
      enabled: true
      sampleRate: 500000
  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
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Questo manifest contiene i seguenti campi:

  • enable: true: abilita esplicitamente il logging degli accessi. I log sono disponibili in Logging.
  • sampleRate: 500000: specifica che il 50% dei pacchetti viene registrato. Puoi utilizzare un valore compreso tra 0 e 1.000.000. GKE converte questo valore in un valore a virgola mobile 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 è necessario impostare anche enable: true. Se enable è impostato su true e sampleRate non viene fornito, GKE imposta enable su false.

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

Assicurati che nel cluster GKE sia in esecuzione la versione 1.31.1-gke.2008000 o successiva.

Per abilitare la scalabilità automatica in base al traffico e il bilanciamento del carico in base alla 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 manifest GCPBackendPolicy definisce un valore 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 in base al traffico, consulta Scalabilità automatica in base al traffico del bilanciatore del carico.

Risoluzione dei problemi

Più GCPBackendPolicy collegati allo stesso Service

Sintomo:

La seguente condizione di stato può verificarsi quando colleghi un GCPBackendPolicy a un Service o 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 Restrizioni e limitazioni.

Soluzione:

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

Criterio di sicurezza di Google Cloud Armor non trovato

Sintomo:

Quando attivi Google 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 il criterio di sicurezza regionale di Google Cloud Armor specificato 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