Questa pagina mostra come configurare il bilanciatore del carico Google Kubernetes Engine (GKE) crea quando esegui il deployment di un gateway in una cluster GKE.
Quando esegui il deployment di un gateway, la configurazione GatewayClass determina quale carico delle risorse create 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 alla tua infrastruttura per soddisfare i requisiti dell'applicazione collegando criteri a gateway, servizi ServiceImports. Dopo aver applicato o modificato un criterio, non è necessario eliminare o di ricreare le risorse Gateway, Route o Service, il criterio viene elaborato il controller gateway e la risorsa sottostante del bilanciatore del carico sono (ri)configurati in base alle (nuove) norme.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Attiva l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
install e poi
inizializzare
con 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 su Nativo VPC di cluster GKE.
- Se si utilizzano le classi gateway interne, è necessario abilitare un 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 opzioni
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 al controller gateway GKE limitazioni e limitazioni, le seguenti limitazioni si applicano in modo specifico ai criteri applicati al gateway di risorse:
GCPGatewayPolicy
risorse possono essere collegate solo a ungateway.networking.k8s.io
Gateway
.Le risorse
GCPGatewayPolicy
devono esistere nello stesso spazio dei nomi della destinazioneGateway
.Quando utilizzi un gateway singolo,
GCPBackendPolicy
e Le risorseHealthCheckPolicy
devono fare riferimento a una risorsaService
.
- Quando utilizzi un gateway multi-cluster,
GCPBackendPolicy
eHealthCheckPolicy
, le risorse devono fare riferimento a una risorsaServiceImport
.
È possibile collegare un solo
GCPGatewayPolicy
a un servizio alla volta. Quando vengono creati due criteriGCPGatewayPolicy
e hanno come target lo stessoService
oServiceImport
, avrà la precedenza il criterio meno recente, mentre il secondo non verranno allegati.I criteri gerarchici non sono supportati con il gateway GKE.
Le risorse
HealthCheckPolicy
eGCPBackendPolicy
devono esistono nello stesso spazio dei nomi della risorsaService
oServiceImport
di destinazione.Le risorse
GCPBackendPolicy
eHealthCheckPolicy
sono strutturate in modo di poter fare riferimento a un solo servizio di backend.GCPBackendPolicy
non supporta le opzioniHEADER_FIELD
oHTTP_COOKIE
per affinità sessione.
Configura l'accesso globale per il gateway interno regionale
Questa sezione descrive una funzionalità disponibile su GKE con la versione 1.24 o successiva.
Per abilitare l'accesso globale con il tuo gateway interno, collega un criterio al 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
Configurazione dei criteri SSL per proteggere il traffico client-bilanciatore del carico
Questa sezione descrive una funzionalità disponibile su GKE con la versione 1.24 o successiva.
Per proteggere il traffico dal client al bilanciatore del carico, configura il criterio SSL aggiungendo
il nome del criterio in GCPGatewayPolicy
. Per impostazione predefinita, il gateway non
abbiano eventuali criteri SSL definiti e collegati.
Assicurati di creare un criterio SSL.
prima di fare riferimento al criterio nel tuo 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 su GKE con la versione 1.24 o successiva.
Puoi utilizzare HealthCheckPolicy
per controllare il controllo di integrità del bilanciatore del carico
impostazioni. Ogni tipo di controllo di integrità (http
, https
, grpc
e http2
) ha un
che puoi definire. Google Cloud crea un'integrità unica
e controllare ogni servizio di backend per ogni servizio GKE.
Affinché il bilanciatore del carico funzioni normalmente, potrebbe essere necessario configurare una
HealthCheckPolicy
per il bilanciatore del carico se il percorso del controllo di integrità non è
standard "/". Questa configurazione è necessaria anche se il percorso richiede
o se devi modificare i parametri del controllo di integrità. Ad esempio, se
il percorso di richiesta predefinito è "/" ma non è possibile accedere al servizio se questa richiesta
e usa "/health" per segnalarne l'integrità, devi configurare
requestPath
nel tuo HealthCheckPolicy
di conseguenza.
Il seguente manifest HealthCheckPolicy
mostra tutti i campi disponibili quando
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 intervallo di controllo, in secondi, per ogni prober del controllo di integrità. Questo è il tempo dall'inizio dal controllo di un prober all'inizio del controllo successivo. Se ometti questo messaggio , il valore predefinito di Google Cloud è 5 secondi. Per ulteriori informazioni, vedi Più probe e frequenza.TIMEOUT
: specifica per quanto tempo Google Cloud attende una risposta a un probe. Il valore diTIMEOUT
deve essere inferiore o uguale alINTERVAL
. Le unità sono in secondi. Ogni probe richiede Codice di risposta HTTP 200 (OK) da consegnare prima del timeout del probe.HEALTHY_THRESHOLD
eUNHEALTHY_THRESHOLD
: specifica il numero di tentativi di connessione sequenziali che devono avere esito positivo o negativo, per almeno uno per cambiare stato di integrità da sano a non salutare o da non salutare a sano. Se ometti uno di questi elementi , il valore predefinito di Google Cloud è 2.PROTOCOL
: specifica un protocollo utilizzati dai sistemi di probe per il controllo di integrità. Per ulteriori informazioni, vedi 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
), la porta denominata (USE_NAMED_PORT
) porta di distribuzione (USE_SERVING_PORT
). Se non specificato, il controllo di integrità segue il comportamento specificato nei campiport
eportName
. Se nessuna delle due opzioniport
oportName
sono specificati. Per impostazione predefinita, questo campo èUSE_SERVING_PORT
.PORT
: un criterio HealthCheckPolicy supporta solo la specifica alla porta per il 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, seleziona una porta corrispondente acontainerPort
di un pod in gestione, anche secontainerPort
fa riferimento a untargetPort
del servizio. Non sei limitato acontainerPorts
a cui fa riferimento untargetPort
di un Servizio.PORT_NAME
: specifica il nome della porta come definito in InstanceGroup.NamedPort.name. Seport
eportName
sono definiti, Google Cloud consideraport
prima del valore.HOST
: il valore dell'intestazione dell'host nell'integrità richiesta di verifica. Questo valore utilizza il parametro RFC 1123 non sono consentite la definizione di un nome host, ad eccezione degli indirizzi IP numerici. Se non specificato o lasciato vuoto, questo valore corrisponde per impostazione predefinita all'indirizzo IP del controllo di integrità.REQUEST_PATH
: specifica il request-path del 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 l'inizio dei dati di risposta. Se non viene specificato o se viene lasciato vuoto, GKE interpreta qualsiasi risposta come integro. I dati della risposta possono essere solo ASCII.PROXY_HEADER
: specifica il tipo di intestazione del proxy. Puoi utilizzareNONE
oPROXY_V1
. Il valore predefinito èNONE
.GRPC_SERVICE_NAME
: un nome facoltativo di gRPC assistenza. Ometti questo campo per specificare tutti i servizi.
Per ulteriori informazioni sui campi HealthCheckPolicy, consulta healthChecks
riferimento.
Configura il criterio di sicurezza del backend Google Cloud Armor per proteggere i tuoi servizi di backend
Questa sezione descrive una funzionalità disponibile su GKE con la versione 1.24 o successiva.
Configura il criterio di sicurezza del backend di Google Cloud Armor aggiungendo il nome di
il tuo criterio di sicurezza a GCPBackendPolicy
per proteggere i tuoi servizi di backend.
Per impostazione predefinita, il gateway non dispone di sicurezza del backend di Google Cloud Armor
definito e allegato.
Assicurati di creare un criterio di sicurezza del backend di Google Cloud Armor.
prima di fare riferimento al criterio nel tuo 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 su GKE con la versione 1.24 o successiva.
Identity-Aware Proxy (IAP) applica i criteri di controllo dell'accesso sui servizi di backend associati a una HTTPRoute. Con questa applicazione, solo gli utenti autenticati le applicazioni a cui è stato assegnato il ruolo Identity and Access Management (IAM) corretto possono per accedere a questi servizi di backend.
Per impostazione predefinita, non viene applicato alcun IAP ai servizi di backend,
devono configurare esplicitamente IAP in un GCPBackendPolicy
.
Per configurare IAP con il gateway, segui questi passaggi:
Abilita IAP per GKE Non configurare il backend (Configurazione di BackendConfig) perché
BackendConfig
è valido solo nel caso di un deployment Ingress.Crea un secret per il tuo IAP:
Nella console Google Cloud, vai alla pagina Credenziali:
Fai clic sul nome del client e scarica il file del client OAuth.
Copia il secret OAuth negli appunti dal file del client OAuth.
Crea un file denominato
iap-secret.txt
.Incolla il secret OAuth nel file
iap-secret.txt
utilizzando il metodo seguente comando:echo -n CLIENT_SECRET > iap-secret.txt kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
Per specificare un criterio IAP che fa riferimento a un secret:
Crea il seguente manifest
GCPBackendPolicy
, sostituisci il rispettivamenteSECRET_NAME
eCLIENT_ID
. Salva il manifest comebackend-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 su GKE con la versione 1.24 o successiva.
Il seguente manifest GCPBackendPolicy
specifica un
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 su GKE con la versione 1.24 o successiva.
Puoi configurare affinità sessione in base ai seguenti criteri:
- Indirizzo IP client
- Cookie generato
Quando configuri l'affinità sessione
per il tuo 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
.
Il seguente manifest GCPBackendPolicy
specifica un'affinità sessione in base al
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 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 su GKE con la versione 1.24 o successiva.
Puoi configurare
timeout per svuotamento della connessione
utilizzando GCPBackendPolicy
. Il timeout per lo svuotamento della connessione è il tempo, in secondi, per
e attenderemo 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 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 rilevamento richieste al backend rimosso. Il bilanciatore del carico non invia nuovi 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 su GKE con la versione 1.24 o successiva.
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
senzalogging
- Puoi impostare
logging.enabled
sufalse
- Puoi impostare
logging.enabled
sutrue
e impostarelogging.sampleRate
su0
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 uno dei seguenti compreso tra 0 e 1.000.000. GKE converte questo valore in valore in virgola mobile nell'intervallo [0, 1] dividendo per 1.000.000. Questo campo è pertinente solo seenable
è impostato sutrue
.sampleRate
è un'opzione facoltativa ma se è configurato, è necessario impostare ancheenable: true
. Seenable
è impostato sutrue
esampleRate
non è quindi fornito GKE impostaenable
sufalse
.
Risoluzione dei problemi
Più elementi GCPBackendPolicy
collegati allo stesso Service
Sintomo:
Quando colleghi un GCPBackendPolicy
, potrebbe verificarsi la seguente condizione di stato
a Service
o 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 Service
o ServiceImport
a cui è già collegato un GCPBackendPolicy
.
Più elementi GCPBackendPolicy
collegati allo stesso Service
o ServiceImport
sono
non supportato con il gateway GKE. Vedi Restrizioni e limitazioni
per ulteriori dettagli.
Soluzione:
Configura un singolo GCPBackendPolicy
che includa tutte le configurazioni personalizzate e
allegalo al tuo Service
o ServiceImport
.
Passaggi successivi
- Scopri di più sulle 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.