Configura le risorse del gateway utilizzando i criteri

Autopilot Standard

---

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 GatewayClass determina il bilanciatore del carico creato da 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 i criteri a gateway, servizi o ServiceImports. Dopo aver applicato o modificato un criterio, non è necessario eliminare o ricreare le risorse Gateway, Route o Service: il criterio viene elaborato dal controller Gateway e la risorsa sottostante del bilanciatore del carico viene (ri)configurata in base al (nuovo) criterio.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti località predefinite, puoi evitare errori in gcloud CLI, come quelli che seguono: One of [--zone, --region] must be supplied: Please specify location.

Requisiti del controller gateway GKE

• Per Standard, GKE versione 1.24 o 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 nativi VPC.
• Se utilizzi GatewayClass interni, devi abilitare una subnet solo proxy.
• Nel cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing.
• Se utilizzi Istio, devi eseguire l'upgrade di Istio 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 limitazioni del controller GKE Gateway, si applicano in particolare le seguenti limitazioni ai criteri applicati alle risorse del 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 dell'elemento Gateway di destinazione.

• Quando utilizzi un singolo 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.

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

• I criteri gerarchici non sono supportati con il gateway GKE.

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

Configura 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 aggiungendo l'accesso globale ricrea la regola di forwarding del bilanciatore del carico interno a livello di regione. Questo upgrade elimina e poi ricrea i bilanciatori del carico Google Cloud, che comportano un'indisponibilità fino a 15 minuti. Consigliamo di eseguire questa operazione durante un periodo di manutenzione per evitare tempi di inattività dell'applicazione.

Configurazione dei criteri SSL per proteggere il traffico client-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 aggiungendone il nome a GCPGatewayPolicy. Per impostazione predefinita, al gateway non è definito e collegato alcun criterio SSL.

Assicurati di creare un criterio SSL prima di fare riferimento al criterio in GCPGatewayPolicy.

Nota: se utilizzi un gateway a livello di regione, assicurati di creare un criterio SSL a livello di regione.

Il seguente manifest di 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

Configura i controlli di integrità

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

Puoi utilizzare 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 è lo 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 non è possibile accedere al tuo servizio in questo percorso della richiesta e utilizza invece "/health" per segnalare lo stato di integrità, devi configurare requestPath in HealthCheckPolicy di conseguenza.

Il seguente manifest HealthCheckPolicy mostra tutti i campi disponibili durante la configurazione di un criterio per il 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 prober del controllo di integrità. Si tratta del tempo che intercorre dall'inizio di un controllo di un prober all'inizio di quello successivo. Se ometti questo parametro, il valore predefinito di Google Cloud è 5 secondi. Per maggiori informazioni, consulta Frequenza e probe multipli.
• TIMEOUT: specifica per quanto tempo Google Cloud attende 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 consegna 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 cambiare lo stato di integrità da integro a non integro o 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 successo per HTTP, HTTPS e HTTP/2 e Criteri di successo per gRPC. Questo parametro è obbligatorio.
• ENABLED: specifica se il logging è attivato o disattivato.
• 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 distribuzione (USE_SERVING_PORT). Se non specificata, 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 la specifica porta per il controllo di integrità del bilanciatore del carico tramite un numero di porta. Se ometti questo parametro, il valore predefinito di Google Cloud è 80. Poiché il bilanciatore del carico invia i probe direttamente all'indirizzo IP del pod, devi selezionare una porta corrispondente a containerPort di un pod in gestione, anche se un targetPort del servizio fa riferimento a containerPort. Non puoi limitare gli elementi a containerPorts a cui fa riferimento un 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 port.
• HOST: il valore dell'intestazione host nella richiesta di controllo di integrità. Questo valore utilizza la definizione RFC 1123 di un nome host. Tuttavia, non sono consentiti indirizzi IP numerici. Se non viene specificato o viene lasciato vuoto, per impostazione predefinita questo valore corrisponde all'indirizzo IP del controllo di integrità.
• REQUEST_PATH: specifica il request-path della richiesta di controllo di integrità. Se non viene specificato o se viene lasciato vuoto, il valore predefinito è /.
• RESPONSE: specifica i byte con cui trovare una corrispondenza con l'inizio dei dati della risposta. Se non viene specificato o non viene lasciato vuoto, GKE interpreta qualsiasi risposta come integro. I dati di risposta possono essere solo in formato ASCII.
• PROXY_HEADER: specifica il tipo di intestazione del 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 riferimento healthChecks.

Configura il criterio 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 il criterio LbPolicy con il criterio GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

Configura il criterio di sicurezza del backend di Google Cloud Armor aggiungendo il nome del criterio di sicurezza a GCPBackendPolicy per proteggere i tuoi servizi di backend. Per impostazione predefinita, al gateway non è stato definito e collegato alcun criterio di sicurezza del backend Google Cloud Armor.

Assicurati di creare un criterio di sicurezza del backend di Google Cloud Armor prima di fare riferimento al criterio in GCPBackendPolicy.

Il seguente manifest GCPBackendPolicy specifica un criterio di sicurezza del backend denominato 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 sui servizi di backend associati a un HTTPRoute. Con questa applicazione, solo le applicazioni o gli utenti autenticati a cui è assegnato il ruolo Identity and Access Management (IAM) corretto possono accedere a questi servizi di backend.

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

Per configurare IAP con il gateway, segui questi passaggi:

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

2. Crea un secret per il tuo 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. Copia il secret OAuth negli appunti dal file del client OAuth.

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

   5. Incolla il secret OAuth nel file iap-secret.txt utilizzando questo 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 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 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.

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

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

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 il criterio LbPolicy con il criterio GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

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

• Indirizzo IP client
• Cookie generato

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

Quando rimuovi una configurazione di affinità sessione da GCPBackendPolicy, il gateway ripristina l'impostazione localityLbPolicy sul 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 riportato nell'output di un comando gcloud CLI, nella UI o con Terraform.

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 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 il criterio LbPolicy con il criterio 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, il 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. Una volta raggiunta la durata del timeout, GKE chiude tutte le connessioni rimanenti al backend.

Logging degli accessi HTTP

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

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

Per impostazione predefinita:

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

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

• Puoi uscire dalla sezione GCPBackendPolicy senza logging
• Puoi impostare logging.enabled su false
• Puoi impostare logging.enabled su true e impostare 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 del logging 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 viene registrato il 50% dei pacchetti. Puoi utilizzare un valore compreso tra 0 e 1.000.000. GKE converte questo valore in un valore a virgola mobile compreso nell'intervallo [0, 1] dividendo 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 è fornito, GKE imposta enable su false.

Risoluzione dei problemi

Più elementi GCPBackendPolicy collegati allo stesso Service

Sintomo:

Quando colleghi un GCPBackendPolicy a un Service o a un ServiceImport, potrebbe verificarsi la seguente condizione di stato:

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 a un ServiceImport a cui è già collegato un GCPBackendPolicy.

Più elementi GCPBackendPolicy collegati allo stesso Service o ServiceImport non sono supportati con il gateway GKE. Consulta Restrizioni e limitazioni per ulteriori dettagli.

Soluzione:

Configura un singolo GCPBackendPolicy che includa tutte le configurazioni personalizzate e collegalo a Service o ServiceImport.

Passaggi successivi

• Scopri di più sul controller gateway.
• Scopri come fare riferimento a un gateway da una risorsa.
• Consulta la documentazione di riferimento dell'API Policy Types.
• Visualizza le definizioni dei tipi di API.