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 crea il bilanciatore del carico. Questo bilanciatore del carico gestito è preconfigurato con impostazioni predefinite che puoi modificare utilizzando un criterio.
Puoi personalizzare le risorse gateway in base ai requisiti della tua infrastruttura o delle tue applicazioni 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 servizio, poiché il criterio viene elaborato dal controller gateway e la risorsa del bilanciatore del carico sottostante 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 initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
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 su cluster native VPC.
- Se utilizzi le classi di gateway interne, 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.
Limitazioni e limitazioni
Oltre alle limitazioni e limitazioni del controller gateway GKE, le seguenti limitazioni si applicano in modo specifico ai criteri applicati alle risorse gateway:
Le risorse
GCPGatewayPolicy
possono essere collegate solo a ungateway.networking.k8s.io
Gateway
.Le risorse
GCPGatewayPolicy
devono esistere nello stesso spazio dei nomi del targetGateway
.Quando utilizzi un gateway di un cluster singolo, le risorse
GCPBackendPolicy
eHealthCheckPolicy
devono fare riferimento a una risorsaService
.
- Quando utilizzi un gateway multi-cluster,
GCPBackendPolicy
eHealthCheckPolicy
, le risorse devono fare riferimento a una risorsaServiceImport
.
È possibile collegare a un servizio un solo
GCPGatewayPolicy
alla volta. Quando vengono creati due criteriGCPGatewayPolicy
che hanno come target lo stessoService
oServiceImport
, il criterio meno recente ha la precedenza, mentre il secondo non viene associato.I criteri gerarchici non sono supportati con il gateway GKE.
Le risorse
HealthCheckPolicy
eGCPBackendPolicy
devono esistere nello stesso spazio dei nomi della risorsaService
oServiceImport
di destinazione.Le risorse
GCPBackendPolicy
eHealthCheckPolicy
sono strutturate in modo da fare riferimento a un solo servizio di backend.
Configura l'accesso globale per il gateway interno a livello di regione
Questa sezione descrive una funzionalità disponibile nei cluster GKE che eseguono la versione 1.24 o successive.
Per abilitare l'accesso globale con il gateway interno, collega un criterio alla risorsa gateway.
Il seguente manifest GCPGatewayPolicy
abilita il gateway interno a livello di regione 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 i criteri SSL per proteggere il traffico client-load-balancer
Questa sezione descrive una funzionalità disponibile nei cluster GKE che eseguono la versione 1.24 o successive.
Per proteggere il traffico client-load-balancer, configura il criterio SSL aggiungendo
il nome del criterio a GCPGatewayPolicy
. Per impostazione predefinita, al gateway non sono
definiti e collegati criteri SSL.
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
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
) prevede dei parametri che puoi definire. Google Cloud crea un controllo di integrità univoco
per ogni servizio di backend per ogni servizio GKE.
Il seguente manifest HealthCheckPolicy
mostra tutti i campi disponibili durante la configurazione di un criterio 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 il check-interval, in secondi, per ogni prober del controllo di integrità. Si tratta del tempo che intercorre tra l'inizio di un controllo del prober e quello del successivo. Se ometti questo parametro, il valore predefinito di Google Cloud è 5 secondi. Per maggiori informazioni, consulta Più probe e frequenza.TIMEOUT
: specifica l'intervallo di tempo durante il quale Google Cloud attende una risposta a un probe. Il valore diTIMEOUT
deve essere inferiore o uguale aINTERVAL
. Le unità sono i secondi. Ogni probe richiede la consegna di un codice di risposta HTTP 200 (OK) prima del timeout del probe.HEALTHY_THRESHOLD
eUNHEALTHY_THRESHOLD
: specifica il numero di tentativi di connessione sequenziale che devono avere esito positivo o negativo, per almeno un prober, per modificare lo stato di integrità da integro a non integro o non integro o non integro. Se ometti uno di questi parametri, il valore predefinito di Google Cloud è 2.PROTOCOL
: specifica un protocollo utilizzato dai sistemi dei probe per il controllo di integrità. Per maggiori 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
), denominata (USE_NAMED_PORT
) o di pubblicazione (USE_SERVING_PORT
). Se non specificata, il controllo di integrità segue il comportamento specificato nei campiport
eportName
. Se non viene specificato néport
néportName
, il valore predefinito di questo campo saràUSE_SERVING_PORT
.PATH
: specifica il request-path a cui deve connettersi il sistema del probe per i controlli di integrità HTTP, HTTPS o HTTP2. Se ometti questo parametro, il valore predefinito di Google Cloud è/
.PORT
: un criterio HealthCheckPolicy supporta solo la specifica della 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 uncontainerPort
dei pod di gestione, anche secontainerPort
fa riferimento a un elementotargetPort
del servizio. Non è limitato acontainerPorts
a cui fa riferimentotargetPort
di un servizio.PORT_NAME
: specifica il nome della porta come definito in InstanceGroup.NamedPort.name. Se sono definiti siaport
siaportName
, Google Cloud considera per primo il valoreport
.HOST
: il valore dell'intestazione host nella richiesta di controllo di integrità. Questo valore utilizza la definizione di nome host nel documento RFC 1123 , ad eccezione degli indirizzi IP numerici che non sono consentiti. Se non specificato o se viene lasciato vuoto, questo valore corrisponde per impostazione predefinita all'indirizzo IP del controllo di integrità.REQUEST_PATH
: specifica il percorso della richiesta di controllo di integrità. Se non specificato o se viene lasciato vuoto, il valore predefinito è/
.RESPONSE
: specifica i byte da abbinare all'inizio dei dati di risposta. Se non specificato o se non viene lasciato vuoto, GKE interpreta qualsiasi risposta come integro. I dati di risposta possono essere solo ASCII.PROXY_HEADER
: specifica il tipo di intestazione proxy. Puoi usareNONE
oPROXY_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 di 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.
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 è definito e collegato alcun criterio di sicurezza backend di 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 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 ai servizi di backend associati a 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, IAP non viene applicato ai servizi di backend, devi configurarlo esplicitamente in un GCPBackendPolicy
.
Per configurare IAP con il gateway:
Abilita IAP per GKE Non configurare il backend (Configurazione di BackendConfig) poiché
BackendConfig
è valido solo nel caso di un deployment Ingress.Crea un secret per il tuo IAP:
Vai alla pagina Credenziali. Pulsante: vai alla pagina Credenziali.
Fai clic sul nome del client e scarica il file del client OAuth.
Dal file del client OAuth, copia il segreto OAuth negli appunti.
Crea un file denominato
iap-secret.txt
.Incolla il secret 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
Per specificare il criterio IAP che fa riferimento a un secret:
Crea il seguente manifest
GCPBackendPolicy
, sostituisci rispettivamenteSECRET_NAME
eCLIENT_ID
. Salva il manifest con il nomebackend-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
Applica il manifest
backend-policy.yaml
:kubectl apply -f backend-policy.yaml
Verifica la configurazione:
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
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. L'impostazione predefinita del campo timeoutSec
è di 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 affinità sessione
Questa sezione descrive una funzionalità disponibile nei cluster GKE che eseguono la versione 1.24 o successive.
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
al valore predefinito, ROUND_ROBIN
.
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 di gcloud CLI, nella UI o con Terraform.
Il seguente manifest GCPBackendPolicy
specifica un'affinità sessione in base all'indirizzo IP client:
Servizio
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
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 in base a 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 le seguenti opzioni per sessionAffinity.type
: CLIENT_IP
, CLIENT_IP_PROTO
, CLIENT_IP_PORT_PROTO
, GENERATED_COOKIE
, HEADER_FIELD
, HTTP_COOKIE
e 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 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 di 60 secondi per lo svuotamento della connessione:
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 al backend rimanenti.
Logging 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 gateway registra tutte le richieste HTTP dai client a Cloud Logging.
- La frequenza di campionamento è 1.000.000, il che significa che vengono registrate tutte le richieste.
Puoi disattivare il logging degli accessi sul tuo gateway utilizzando un GCPBackendPolicy
in tre modi:
- Puoi uscire da
GCPBackendPolicy
senza la sezionelogging
- Puoi impostare
logging.enabled
sufalse
- Puoi impostare
logging.enabled
sutrue
elogging.sampleRate
su0
Puoi anche configurare la frequenza di campionamento dei log di accesso.
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
Il file manifest include 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 in virgola mobile compreso nell'intervallo [0, 1] dividendo per 1.000.000. Questo campo è pertinente solo seenable
è impostato sutrue
.sampleRate
è un campo facoltativo, ma se è configurato, è necessario impostare ancheenable: true
. Seenable
è impostato sutrue
e non viene fornitosampleRate
, GKE impostaenable
sufalse
.
Risoluzione dei problemi
Più GCPBackendPolicy
collegati allo stesso Service
Sintomo:
Quando colleghi un elemento GCPBackendPolicy
a un Service
o a un ServiceImport
, è possibile che si verifichi 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ù GCPBackendPolicy
collegati allo stesso Service
o ServiceImport
non sono supportati con il gateway GKE. Per ulteriori dettagli, consulta Restrizioni e limitazioni.
Soluzione alternativa:
Configura un singolo GCPBackendPolicy
che includa tutte le configurazioni personalizzate e associalo a Service
o ServiceImport
.
Passaggi successivi
- Scopri di più sul controller gateway.
- Scopri come fare riferimento a un gateway da una risorsa.