Questa pagina mostra come attivare e utilizzare i servizi multi-cluster (MCS). Per scoprire di più sul funzionamento e sui vantaggi di MCS, consulta Multi-cluster Services.
La funzionalità MCS di Google Kubernetes Engine (GKE) estende della copertura del servizio Kubernetes oltre i confini del cluster e ti consente di scoprire e richiamare i servizi in più cluster GKE. Puoi esportare un sottoinsieme di servizi esistenti o nuovi servizi.
Quando esporti un servizio con MCS, quel servizio diventa disponibile in tutti i cluster flotta.
Risorse Google Cloud gestite da MCS
MCS gestisce i seguenti componenti di Google Cloud:
Cloud DNS: MCS configura le zone Cloud DNS e per ogni servizio esportato nel tuo cluster del parco risorse. Questo ti consente di connetterti ai servizi in esecuzione in cluster. Le zone e i record vengono creati, letti, aggiornati ed eliminati in base sui Servizi che scegli di esportare in vari cluster.
Regole firewall: MCS configura le regole firewall che consentono I pod comunicano tra loro nei cluster all'interno del tuo parco risorse. Le regole del firewall vengono create, lette, aggiornate ed eliminate in base ai cluster che aggiungi al tuo parco risorse. Queste regole sono simili alle regole usate da GKE per abilitare la comunicazione tra i pod all'interno di un cluster GKE.
Cloud Service Mesh: MCS utilizza Cloud Service Mesh come piano di controllo per tenere traccia degli endpoint e della loro integrità nei cluster.
Requisiti
MCS prevede i seguenti requisiti:
MCS supporta l'esportazione dei servizi solo dai cluster GKE nativi VPC su Google Cloud. Per ulteriori informazioni, vedi Creazione di un cluster nativo di VPC. Non puoi utilizzare i cluster GKE standard non nativi VPC.
La connettività tra i cluster dipende dai cluster in esecuzione all'interno della stessa rete VPC, in reti VPC in peering o condivise. In caso contrario, le chiamate ai servizi esterni non potranno superare il confine della rete.
Sebbene un parco risorse possa includere più progetti Google Cloud e VPC di reti, un singolo servizio multi-cluster deve essere esportato da un e una singola rete VPC.
MCS non è supportato con criteri di rete.
Nei cluster deve essere abilitato il componente aggiuntivo
HttpLoadBalancing
. Assicurati che il plug-inHttpLoadBalancing
sia attivo. Il componente aggiuntivoHttpLoadBalancing
è è attiva per impostazione predefinita e non deve essere disattivata.
Prezzi
I servizi multi-cluster sono inclusi nella Tariffa di gestione dei cluster GKE senza costi aggiuntivi per l'utilizzo. Devi abilitare l'API Traffic Director, ma MCS lo fa non sono soggetti ad addebiti per gli endpoint Cloud Service Mesh. La licenza di GKE Enterprise è per l'uso di MCS.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
Installa Google Cloud SDK.
Attiva l'API Google Kubernetes Engine:
Abilita MCS, parco risorse (hub), Resource Manager, Cloud Service Mesh, e le API Cloud DNS:
gcloud services enable \ multiclusterservicediscovery.googleapis.com \ gkehub.googleapis.com \ cloudresourcemanager.googleapis.com \ trafficdirector.googleapis.com \ dns.googleapis.com \ --project=PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID progetto del in cui prevedi di registrare i cluster in un parco risorse.
Abilitazione di MCS nel progetto
MCS richiede la registrazione dei cluster GKE partecipanti nello stesso parco risorse. Una volta attivata la funzionalità MCS per un parco risorse, tutti i cluster possono esportare i servizi tra i cluster del parco risorse.
Sebbene MCS richieda la registrazione per un parco risorse, non richiede di abilitare la piattaforma GKE Enterprise.
GKE Enterprise
Se l'API GKE Enterprise è abilitata nel progetto host del parco risorse come prerequisito per l'utilizzo di altri componenti di GKE Enterprise, a tutti i cluster registrati nel parco risorse del progetto verrà addebitato il costo in base ai prezzi di GKE Enterprise. Questo modello di prezzo ti consente di utilizzare tutte le funzionalità di GKE Enterprise sui cluster registrati con un unico addebito per vCPU. Puoi verificare se l'API GKE Enterprise è abilitata utilizzando il seguente comando:
gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com
Se l'output è simile al seguente, la piattaforma GKE Enterprise completa è abilitata e Per tutti i cluster registrati nel parco risorse verranno addebitati i costi di GKE Enterprise:
anthos.googleapis.com Anthos API
Se non è previsto, contatta l'amministratore del progetto.
Un output vuoto indica che GKE Enterprise non è abilitato.
Abilitazione di MCS nel cluster GKE
Abilita la funzionalità MCS per il parco risorse del tuo progetto:
gcloud container fleet multi-cluster-services enable \ --project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID del progetto in cui prevedi di registrare i tuoi cluster in un parco risorse. Questo è il tuo progetto host del parco risorse.Registra i cluster GKE nel parco risorse. Ti consigliamo vivamente di registrare il cluster con la federazione delle identità per i carichi di lavoro per GKE abilitata. Se non attivi la federazione delle identità per i carichi di lavoro per GKE, devi registrare il cluster con un account di servizio Google Cloud per l'autenticazione e completare i passaggi aggiuntivi descritti in Autenticazione degli account di servizio.
Per registrare il cluster con la federazione delle identità per i carichi di lavoro per GKE, esegui questo comando:
gcloud container fleet memberships register MEMBERSHIP_NAME \ --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \ --enable-workload-identity \ --project PROJECT_ID
Sostituisci quanto segue:
MEMBERSHIP_NAME
: il nome membro che scegli di rappresentare in modo univoco il cluster nel parco risorse. In genere, il nome dell'appartenenza al parco risorse di un cluster corrisponde al nome del cluster, ma potrebbe essere necessario specificare un nuovo nome se nel parco risorse esiste già un altro cluster con il nome originale.CLUSTER_LOCATION
: la zona o la regione in cui si trova il cluster.CLUSTER_NAME
: il nome del cluster.
Concedi le autorizzazioni IAM (Identity and Access Management) necessarie per MCS Importer:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"
Sostituisci
PROJECT_ID
con l'ID progetto del progetto host del parco risorse.Assicurati che ogni cluster nel parco risorse disponga di uno spazio dei nomi in cui condividere i servizi. Se necessario, crea uno spazio dei nomi utilizzando il comando seguente:
kubectl create ns NAMESPACE
Sostituisci
NAMESPACE
con un nome per lo spazio dei nomi.Per verificare che MCS sia abilitato, esegui il seguente comando:
gcloud container fleet multi-cluster-services describe \ --project PROJECT_ID
L'output è simile al seguente:
createTime: '2021-08-10T13:05:23.512044937Z' membershipStates: projects/PROJECT_ID/locations/global/memberships/MCS_NAME: state: code: OK description: Firewall successfully updated updateTime: '2021-08-10T13:14:45.173444870Z' name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {}
Se il valore di
state
non èACTIVE
, consulta la sezione sulla risoluzione dei problemi.
Autenticazione degli account di servizio
Se hai registrato i tuoi cluster GKE a un parco risorse utilizzando un account di servizio, devi eseguire ulteriori passaggi per autenticare l'account di servizio.
MCS esegue il deployment di un componente chiamato gke-mcs-importer
. Questo componente riceve aggiornamenti degli endpoint da Cloud Service Mesh, pertanto, per attivare MCS, devi concedere al tuo account di servizio l'autorizzazione a leggere le informazioni da Cloud Service Mesh.
Quando utilizzi un account di servizio, puoi utilizzare l'account di servizio predefinito di Compute Engine o il tuo account di servizio del nodo:
Se utilizzi un Account di servizio predefinito Compute Engine, abilita i seguenti ambiti:
https://www.googleapis.com/auth/compute.readonly
https://www.googleapis.com/auth/cloud-platform
Per scoprire di più sull'attivazione degli ambiti, consulta Modificare l'account di servizio e gli ambiti di accesso per un'istanza.
Se utilizzi il tuo proprio account di servizio nodo, assegna il ruolo
roles/compute.networkViewer
al tuo account di servizio.
Utilizzo di MCS
Le sezioni seguenti mostrano come utilizzare MCS. MCS utilizza API dei servizi multi-cluster Kubernetes.
Registrazione di un servizio per l'esportazione
Per registrare un servizio per l'esportazione in altri cluster del tuo parco risorse, completa segui questi passaggi:
Crea un oggetto
ServiceExport
denominatoexport.yaml
:# export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: NAMESPACE name: SERVICE_EXPORT_NAME
Sostituisci quanto segue:
NAMESPACE
: lo spazio dei nomi diServiceExport
. Questo spazio dei nomi deve corrispondere a quello del servizio che stai esportando.SERVICE_EXPORT_NAME
: il nome di un servizio nel tuo che vuoi esportare in altri cluster del tuo parco risorse.
Crea la risorsa
ServiceExport
eseguendo il seguente comando:kubectl apply -f export.yaml
La sincronizzazione dell'esportazione iniziale del tuo servizio richiede circa cinque minuti cluster registrati nel tuo parco risorse. Dopo l'esportazione di un servizio, le sincronizzazioni degli endpoint successive vengono eseguite immediatamente.
Puoi esportare lo stesso servizio da più cluster per creare un singolo servizio
endpoint di servizio multi-cluster disponibile con distribuzione del traffico su
cluster. Prima di esportare servizi con lo stesso nome e spazio dei nomi, assicurati di volerli raggruppare in questo modo. Sconsigliamo di
esportare i servizi negli spazi dei nomi default
e kube-system
a causa
l'elevata probabilità di conflitti tra nomi involontari
per il raggruppamento. Se esporti più di cinque servizi con lo stesso nome e
dello spazio dei nomi, la distribuzione del traffico sui servizi importati potrebbe essere limitata a cinque
per i servizi esportati.
Utilizzo di servizi cross-cluster
MCS supporta solo ClusterSetIP e servizi headless. Sono disponibili solo i record DNS "A".
Dopo aver creato un oggetto ServiceExport
, il seguente nome di dominio viene risolto in
il servizio esportato da qualsiasi pod in qualsiasi cluster del parco risorse:
SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local
L'output include i seguenti valori:
SERVICE_EXPORT_NAME
eNAMESPACE
: i valori che definisci nell'oggettoServiceExport
.
Per i servizi ClusterSetIP, il dominio si risolve in ClusterSetIP
. Tu
può trovare questo valore individuando l'oggetto ServiceImport
in un cluster
spazio dei nomi in cui è stato creato l'oggetto ServiceExport
. ServiceImport
viene creato automaticamente.
Ad esempio:
kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
namespace: EXPORTED-SERVICE-NAMESPACE
name: external-svc-SERVICE-EXPORT-TARGET
status:
ports:
- name: https
port: 443
protocol: TCP
targetPort: 443
ips: CLUSTER_SET_IP
MCS crea un oggetto Endpoints
nell'ambito dell'importazione di un Service
in un cluster. Esaminando questo oggetto, puoi monitorare l'avanzamento dell'importazione di un servizio. Per trovare il nome dell'oggetto Endpoints
, cerca il valore dell'annotazione net.gke.io/derived-service
in un oggetto ServiceImport
corrispondente al servizio importato. Ad esempio:
kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
namespace: EXPORTED-SERVICE-NAMESPACE
name: external-svc-SERVICE-EXPORT-TARGET
Successivamente, cerca l'oggetto Endpoints
per verificare se MCS ha già propagato gli endpoint al cluster di importazione. L'oggetto Endpoints
viene creato nello stesso spazio dei nomi dell'oggetto ServiceImport
, con il nome memorizzato nell'annotazione net.gke.io/derived-service
. Ad esempio:
kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE
Sostituisci quanto segue:
DERIVED_SERVICE_NAME
: il valore del parametro l'annotazionenet.gke.io/derived-service
sull'oggettoServiceImport
.NAMESPACE
: lo spazio dei nomi dell'oggettoServiceExport
.
Puoi trovare ulteriori informazioni sullo stato di integrità degli endpoint utilizzando il Dashboard di Cloud Service Mesh nella console Google Cloud.
Per i servizi headless, il dominio si risolve nell'elenco di indirizzi IP del nei cluster in esportazione. Ogni pod di backend con un nome host indirizzabile in modo indipendente con un nome di dominio del seguente formato:
HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local
L'output include i seguenti valori:
SERVICE_EXPORT_NAME
eNAMESPACE
: i valori che definisci nell'oggettoServiceExport
.MEMBERSHIP_NAME
: l'identificatore univoco nel parco risorse per il cluster in cui si trova il pod.LOCATION
: la località dell'abbonamento. Gli abbonamenti sonoglobal
o la loro posizione è una delle regioni o delle zone in cui si trova il pod, ad esempious-central1
.HOSTNAME
: il nome host del pod.
Puoi anche gestire un pod di backend con un nome host esportato da un cluster registrato con un'appartenenza globale, utilizzando un nome di dominio simile a formato:
HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local
Disabilitazione di MCS
Per disattivare MCS, completa i seguenti passaggi:
Per ogni cluster del tuo parco risorse, elimina ogni oggetto ServiceExport che hai creato:
kubectl delete serviceexport SERVICE_EXPORT_NAME \ -n NAMESPACE
Sostituisci quanto segue:
SERVICE_EXPORT_NAME
: il nome del tuo Oggetto ServiceExport.NAMESPACE
: lo spazio dei nomi diServiceExport
.
Verifica che
ServiceExport
scompaia dall'elenco dopo 30 minuti.Annullare la registrazione dei cluster del parco risorse se non devono essere registrati per un altro scopo.
Disattiva la funzionalità
multiclusterservicediscovery
:gcloud container fleet multi-cluster-services disable \ --project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID progetto del progetto in cui hai registrato i cluster.Disattiva l'API per MCS:
gcloud services disable multiclusterservicediscovery.googleapis.com \ --project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID progetto del progetto in cui hai registrato i cluster.
Limitazioni
I seguenti limiti non vengono applicati in modo forzato e, in alcuni casi, puoi superarli a seconda del carico nei cluster o nel progetto e del tasso di rotazione degli endpoint. Tuttavia, potresti riscontrare problemi di prestazioni quando queste limitazioni sono state superate.
Esportazione dei cluster: un singolo servizio, identificato da un nome nello spazio dei nomi, può essere esportato in sicurezza da un massimo di 5 cluster contemporaneamente. Superato tale limite, è possibile che solo un sottoinsieme gli endpoint possono essere importati nei cluster che utilizzano. Puoi esportare diversi Servizi di diversi sottoinsiemi di cluster.
Il numero di pod dietro un singolo servizio: è sicuro se mantieni al di sotto di 250 pod dietro un singolo servizio. È lo stesso limitazione del servizio a un singolo cluster avere. Con carichi di lavoro relativamente statici e un numero ridotto di cluster multi-cluster servizi, potrebbe essere possibile superare significativamente questo numero in migliaia di endpoint per servizio. Come per i servizi a cluster singolo, gli endpoint vengono controllati da
kube-proxy
su ogni nodo. Quando si va oltre dei cluster, soprattutto quando si esportano da più cluster contemporaneamente, con nodi più grandi.Il numero di servizi multi-cluster esportati contemporaneamente: consigliamo di esportare contemporaneamente non più di 250 porte di servizio univoche, identificate dal nome nello spazio dei nomi di un servizio e dalle porte dichiarate. Ad esempio, l'esportazione di un servizio che espone le porte 80 e 443 rispetto a 2 dei 250 limiti di porte di servizio univoci. Servizi con lo stesso il nome con spazio dei nomi esportato da più cluster viene conteggiato come un unico assistenza. Il servizio con due porte menzionato in precedenza verrà comunque conteggiato solo per due porte se viene esportato da cinque cluster contemporaneamente. Ciascuna il servizio multi-cluster viene conteggiato ai fini del calcolo Quota di servizi di backend, e ogni cluster o zona di esportazione crea gruppo di endpoint di rete (NEG).
Tipi di servizi
MCS supporta solo ClusterSetIP e servizi headless. I servizi NodePort e LoadBalancer non sono supportati e potrebbero comportare un comportamento imprevisto.
Utilizzo dell'agente IPmasq con MCS
MCS funziona come previsto quando utilizzi un indirizzo IP di pod predefinito o non mascherato intervallo.
Se utilizzi un intervallo IP di pod personalizzato o un agente IPmasq personalizzato ConfigMap, il traffico MCS il mascheramento. Ciò impedisce il funzionamento di MCS perché le regole firewall consentono solo il traffico dagli IP dei pod.
Per evitare questo problema, devi utilizzare l'intervallo IP del pod predefinito o specificare tutti gli intervalli IP del pod nel campo nonMasqueradeCIDRs
del ConfigMap dell'agente IPmasq.
Se usi Autopilot o devi utilizzare un intervallo IP di pod non predefinito,
non è in grado di specificare tutti gli intervalli IP di pod in ConfigMap,
utilizza il criterio NAT in uscita per configurare il mascheramento IP.
Riutilizzo di numeri di porta all'interno di un servizio MCS
Non puoi riutilizzare lo stesso numero di porta all'interno di un servizio MCS anche se i protocolli sono diversi.
Ciò si applica sia all'interno di un servizio Kubernetes che a tutti i servizi Kubernetes Servizi per un servizio MCS.
MCS con cluster in più progetti
Non puoi esportare un servizio se questo viene già esportato da altri cluster in un progetto diverso del parco risorse con lo stesso nome e spazio dei nomi. Puoi accedere al servizio in altri cluster del parco risorse in altri progetti, ma questi cluster non possono esportare lo stesso servizio nello stesso spazio dei nomi.
Risoluzione dei problemi
Le seguenti sezioni forniscono suggerimenti per la risoluzione dei problemi relativi a MCS.
Visualizzazione di featureState
Visualizzare lo stato della funzionalità può aiutarti a verificare se MCS è stato configurato correttamente. Puoi visualizzare lo stato della funzionalità MCS utilizzando il seguente comando:
gcloud container fleet multi-cluster-services describe
L'output è simile al seguente:
createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
state:
code: OK
description: Firewall successfully updated
updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
state: ACTIVE
spec: {}
I campi più utili per la risoluzione dei problemi sono code
e description
.
Codici in featureState
Un codice indica lo stato generale del membro in relazione a MCS. Puoi trovare questi campi nel campo state.code
. Esistono tre possibili codici:
OK
: l'abbonamento è stato aggiunto a MCS ed è pronto per per gli utilizzi odierni.WARNING
: MCS è in fase di riconciliazione della configurazione dell'abbonamento. Il campo della descrizione può fornire ulteriori informazioni ha causato questo codice.FAILED
: questo abbonamento non è stato aggiunto a MCS. Altri abbonamenti in il parco risorse con un codiceOK
non è interessato da questo abbonamento aFAILED
. Il campo della descrizione può fornire ulteriori informazioni ha causato questo codice.ERROR
: a questo abbonamento mancano delle risorse. Altri abbonamenti in il parco risorse con un codiceOK
non è interessato da questo abbonamento aERROR
. Il campo della descrizione può fornire ulteriori informazioni ha causato questo codice.
Descrizioni in featureState
Una descrizione fornisce ulteriori informazioni sullo stato dell'abbonamento in
MCS. Puoi trovare queste descrizioni nel campo state.description
e visualizzare le seguenti descrizioni:
Firewall successfully created
: questo messaggio indica che la regola firewall del membro è stata creata e/o aggiornata correttamente. La il codice dell'abbonamento èOK
.Firewall creation pending
: questo messaggio indica che la regola firewall del membro è in attesa di creazione o aggiornamento. Il codice dell'abbonamento èWARNING
. Potrebbero verificarsi problemi di aggiornamento e connessione a questo abbonamento sono stati aggiunti nuovi servizi e iscrizioni multi-cluster mentre la regola firewall è in attesa.GKE Cluster missing
: questo messaggio indica che il cluster GKE registrato non è disponibile e/o è stato eliminato. Il codice dell'abbonamento èERROR
. È necessario annullare manualmente la registrazione di questo gruppo dal parco risorse dopo l'eliminazione di un cluster GKE.Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required
: questo messaggio indica che sono presenti errori interni StatusForbidden (403) e che il codice dell'abbonamento èFAILED
. Questo errore si verifica nei seguenti scenari:Non hai attivato le API necessarie nel progetto del membro.
Se il cluster membro si trova in un progetto separato da quello del parco risorse, consulta configurazione tra progetti per assicurarti di aver completato tutte le operazioni necessarie. passaggi. Se hai completato tutti i passaggi, assicurati che le API seguenti siano abilitate nel progetto di registrazione con seguenti comandi:
gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID gcloud services enable dns.googleapis.com --project PROJECT_ID gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID progetto del progetto in cui hai registrato i cluster.L'account di servizio
mcsd
ogkehub
richiede più autorizzazioni nel progetto del membro.Gli account di servizio
mcsd
egkehub
dovrebbero essere stati creato nel progetto host del parco risorse con tutte le autorizzazioni necessarie. Per verificare l'esistenza degli account di servizio, esegui i seguenti comandi:gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub
Sostituisci
PROJECT_ID
con l'ID progetto del progetto host del parco risorse.
Questi comandi dovrebbero mostrare il nome completo degli account di servizio
mcsd
egkehub
.Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity
: questo messaggio viene visualizzato quando i cluster ospitati in VPC diversi sono registrati nello stesso parco risorse. Stato elenco èOK
. La rete VPC di un cluster è definita dalla rete di NetworkConfig. I servizi multi-cluster richiedono una rete piatta e questi VPC devono essere eseguito attivamente in peering per permettere ai servizi multi-cluster di connettersi correttamente a ogni e l'altro. Per scoprire di più, consulta Eseguire il peering di due reti.Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.
: questo messaggio ti ricorda che i cluster tra progetti richiedono passaggi di configurazione aggiuntivi. Lo stato dell'abbonamento èOK
. Le iscrizioni tra progetti sono definite come un cluster di membri che non si trova nello stesso progetto del parco risorse. Per ulteriori informazioni, consulta la configurazione tra progetti.Non-GKE clusters are currently not supported
: questo ti ricorda che MCS supporta solo i cluster GKE. I cluster non GKE non possono essere aggiunti a MCS. Stato iscrizione correnteFAILED
.
Problemi noti
Servizi MCS con più porte
Esiste un problema noto con i servizi multi-cluster con più porte (TCP/UDP) su GKE Dataplane V2 in cui alcuni endpoint non sono programmati nel dataplane. Questo problema le versioni di GKE precedenti alla 1.26.3-gke.400.
Come soluzione alternativa, quando utilizzi GKE Dataplane V2, utilizza più MCS con una singola porta anziché un MCS con più porte.
Numero di porta riutilizzato all'interno di un servizio MCS
Non puoi riutilizzare lo stesso numero di porta all'interno di un servizio MCS anche se i protocolli sono diversi.
Ciò si applica sia all'interno di un servizio Kubernetes che a tutti i servizi Kubernetes Servizi per un servizio MCS.
Questo comportamento verrà corretto in una release futura di MCS.
MCS con VPC condiviso
Con l'attuale implementazione di MCS, se esegui il deployment di più di un parco risorse nel sullo stesso VPC condiviso, i metadati sono condivisi tra i parchi risorse. Quando un servizio viene creato in un parco, i metadati del servizio vengono esportati o importati in tutti gli altri parchi che fanno parte dello stesso VPC condiviso e sono visibili all'utente.
Questo comportamento verrà corretto in una release futura di MCS.
Il controllo di integrità utilizza la porta predefinita anziché containerPort
Quando esegui il deployment di un servizio con un campo targetPort
che fa riferimento a una porta denominata in un deployment, MCS configura la porta predefinita per il controllo di integrità anziché il containerPort
specificato.
Per evitare questo problema, utilizza i valori numerici nel campo Servizio
ports.targetPort
e il campo Deployment
readinessProbe.httpGet.port
anziché valori denominati.
Questo comportamento verrà risolto in una prossima release di MCS.
Passaggi successivi
- Scopri di più sui servizi.
- Scopri come esporre le app con i servizi.
- Implementa un esempio di servizi multi-cluster di base.