Configurazione dei servizi multi-cluster

Questa pagina mostra come abilitare e utilizzare i servizi multi-cluster (MCS). Per saperne di più su come funziona MCS e sui suoi vantaggi, consulta Servizi multi-cluster.

La funzionalità MCS di Google Kubernetes Engine (GKE) estende la copertura del Servizio Kubernetes oltre i confini del cluster e consente di scoprire e richiamare i servizi su più cluster GKE. Puoi esportare un sottoinsieme di servizi esistenti o nuovi.

Quando esporti un servizio con MCS, quel servizio sarà disponibile in tutti i cluster nel tuo parco risorse.

Risorse Google Cloud gestite da MCS

MCS gestisce i seguenti componenti di Google Cloud:

  • Cloud DNS: MCS configura le zone e i record di Cloud DNS per ogni servizio esportato nei tuoi cluster del parco risorse. In questo modo puoi connetterti ai servizi in esecuzione in altri cluster. Queste zone e i record vengono creati, letti, aggiornati ed eliminati in base ai servizi che scegli di esportare nei cluster.

  • Regole firewall: MCS configura regole firewall che consentono ai pod di comunicare tra loro nei cluster all'interno del parco risorse. Le regole firewall vengono create, lette, aggiornate ed eliminate in base ai cluster che aggiungi al tuo parco risorse. Queste regole sono simili a quelle che GKE crea per abilitare la comunicazione tra i pod all'interno di un cluster GKE.

  • Traffic Director: MCS utilizza Traffic Director come piano di controllo per tenere traccia degli endpoint e della loro integrità in tutti i cluster.

Requisiti

MCS ha i seguenti requisiti:

  • MCS supporta solo l'esportazione di servizi da cluster GKE nativi di VPC su Google Cloud. Per maggiori informazioni, consulta la sezione Creazione di un cluster nativo di VPC. Non puoi utilizzare cluster GKE Standard non VPC nativi.

  • La connettività tra i cluster dipende dai cluster in esecuzione nella stessa rete VPC, in reti VPC in peering o condivise. In caso contrario, le chiamate ai servizi esterni non potranno attraversare i confini della rete.

  • Mentre un parco risorse può comprendere più progetti Google Cloud e reti VPC, è necessario esportare un singolo servizio multi-cluster da un singolo progetto e una singola rete VPC.

  • MCS non è supportato con i criteri di rete.

  • Nei cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing. Assicurati che il componente aggiuntivo HttpLoadBalancing sia abilitato. Il componente aggiuntivo HttpLoadBalancing è attivato per impostazione predefinita e non deve essere disattivato.

Prezzi

I servizi multi-cluster sono inclusi nella tariffa di gestione dei cluster GKE e non hanno costi aggiuntivi per l'utilizzo. Devi abilitare l'API Traffic Director, ma MCS non comporta alcun addebito per l'endpoint di Traffic Director. Le licenze di GKE Enterprise non sono necessarie per utilizzare MCS.

Prima di iniziare

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

  1. Installa Google Cloud SDK.

  2. Abilita l'API Google Kubernetes Engine:

    Abilita l'API Google Kubernetes Engine

  3. Abilita le API MCS, parco risorse (hub), Resource Manager, Traffic Director e 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 progetto in cui prevedi di registrare i cluster in un parco risorse.

Abilitazione di MCS nel progetto

MCS richiede che i cluster GKE partecipanti siano registrati nello stesso parco risorse. Una volta abilitata la funzionalità MCS per un parco risorse, qualsiasi cluster potrà esportare i servizi tra i cluster del parco risorse.

Anche se MCS richiede la registrazione a un parco risorse, non richiede l'abilitazione della piattaforma GKE Enterprise.

GKE Enterprise

Se l'API GKE Enterprise è abilitata nel progetto host del tuo parco risorse come prerequisito per l'utilizzo di altri componenti GKE Enterprise, per tutti i cluster registrati nel parco risorse del progetto vengono addebitati i costi in base ai prezzi di GKE Enterprise. Questo modello di prezzi 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, viene abilitata la piattaforma GKE Enterprise completa e tutti i cluster registrati nel parco risorse saranno soggetti agli addebiti di GKE Enterprise:

anthos.googleapis.com                        Anthos API

Se si tratta di un imprevisto, contatta l'amministratore del progetto.

Un output vuoto indica che GKE Enterprise non è abilitato.

Abilitazione di MCS sul tuo cluster GKE

  1. 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 progetto del progetto in cui prevedi di registrare i cluster in un parco risorse. Questo è il tuo progetto host del parco risorse.

  2. Registra i cluster GKE nel parco risorse. Ti consigliamo vivamente di registrare il cluster con Federazione delle identità di Workload per GKE abilitata. Se non abiliti la federazione di Workload Identity 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 Workload Identity Federation 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 dell'appartenenza che scegli per rappresentare il cluster nel parco risorse in modo univoco. In genere, il nome dell'appartenenza del parco risorse di un cluster è il nome del cluster, ma potresti dover 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.

  3. Concedi le autorizzazioni IAM (Identity and Access Management) necessarie per l'importatore MCS:

    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.

  4. Assicurati che ogni cluster nel parco risorse abbia uno spazio dei nomi in cui condividere i servizi. Se necessario, crea uno spazio dei nomi utilizzando il seguente comando:

    kubectl create ns NAMESPACE

    Sostituisci NAMESPACE con un nome per lo spazio dei nomi.

  5. Per verificare che MCS sia abilitato, esegui questo 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 relativa alla risoluzione dei problemi.

Autenticazione degli account di servizio

Se hai registrato i tuoi cluster GKE in 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 di endpoint da Traffic Director, pertanto, durante l'abilitazione di MCS, devi concedere al tuo account di servizio l'autorizzazione a leggere le informazioni da Traffic Director.

Quando utilizzi un account di servizio, puoi utilizzare l'account di servizio predefinito di Compute Engine o il tuo account di servizio nodo:

Utilizzo di MCS

Le sezioni seguenti spiegano come utilizzare MCS. MCS utilizza l'API dei servizi multi-cluster Kubernetes.

Registrazione di un servizio per l'esportazione

Per registrare un servizio per l'esportazione in altri cluster all'interno del tuo parco risorse, completa questi passaggi:

  1. Crea un oggetto ServiceExport denominato export.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 dell'oggetto ServiceExport. Questo spazio dei nomi deve corrispondere a quello del servizio che stai esportando.
    • SERVICE_EXPORT_NAME: il nome di un servizio del cluster che vuoi esportare in altri cluster all'interno del parco risorse.

  2. Crea la risorsa ServiceExport eseguendo questo comando:

    kubectl apply -f export.yaml

L'esportazione iniziale del servizio richiede circa cinque minuti per la sincronizzazione con i cluster registrati nel tuo parco risorse. Dopo l'esportazione di un servizio, le sincronizzazioni successive degli endpoint avvengono immediatamente.

Puoi esportare lo stesso servizio da più cluster per creare un singolo endpoint di servizio multi-cluster ad alta disponibilità con distribuzione del traffico tra i cluster. Prima di esportare i servizi che hanno lo stesso nome e lo stesso spazio dei nomi, assicurati che vengano raggruppati in questo modo. Sconsigliamo di esportare i servizi negli spazi dei nomi default e kube-system a causa dell'elevata probabilità di conflitti di nomi involontari e dei risultanti raggruppamenti indesiderati. Se esporti più di cinque servizi con lo stesso nome e lo stesso spazio dei nomi, la distribuzione del traffico sui servizi importati potrebbe essere limitata a cinque 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 si risolve nel 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 e NAMESPACE: i valori che definisci nell'oggetto ServiceExport.

Per i servizi ClusterSetIP, il dominio viene risolto nel ClusterSetIP. Puoi trovare questo valore individuando l'oggetto ServiceImport in un cluster nello spazio dei nomi in cui è stato creato l'oggetto ServiceExport. L'oggetto 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 come parte dell'importazione di un Service in un cluster. Analizzando 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 su 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

Quindi, cerca l'oggetto Endpoints per verificare se MCS ha già propagato gli endpoint nel cluster di importazione. L'oggetto Endpoints viene creato nello stesso spazio dei nomi dell'oggetto ServiceImport, sotto il nome archiviato 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 dell'annotazione net.gke.io/derived-service nell'oggetto ServiceImport.
  • NAMESPACE: lo spazio dei nomi dell'oggetto ServiceExport.

Puoi trovare ulteriori informazioni sullo stato di integrità degli endpoint utilizzando la dashboard di Traffic Director nella console Google Cloud.

Per i servizi headless, il dominio viene risolto nell'elenco di indirizzi IP degli endpoint nei cluster di esportazione. Inoltre, ogni pod di backend con un nome host può essere indirizzato in modo indipendente con un nome di dominio nel formato seguente:

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

L'output include i seguenti valori:

  • SERVICE_EXPORT_NAME e NAMESPACE: i valori che definisci nell'oggetto ServiceExport.
  • MEMBERSHIP_NAME: l'identificatore univoco nel parco risorse per il cluster in cui si trova il pod.
  • LOCATION: la località dell'abbonamento. Gli abbonamenti sono global o la loro località corrisponde a una delle regioni o delle zone in cui si trova il pod, ad esempio us-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 con il seguente formato:

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Disabilitazione di MCS

Per disabilitare MCS, completa i seguenti passaggi:

  1. Per ogni cluster nel 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 dell'oggetto ServiceExport.
    • NAMESPACE: lo spazio dei nomi dell'oggetto ServiceExport.

  2. Annulla la registrazione dei cluster dal parco risorse se non devono essere registrati per un altro scopo.

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

  4. Disabilita 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 della percentuale di abbandono degli endpoint. Tuttavia, quando queste limitazioni vengono superate, potresti riscontrare problemi di prestazioni.

  • Esportazione dei cluster: un singolo servizio, identificato da un nome con spazio dei nomi, può essere esportato in modo sicuro da un massimo di 5 cluster contemporaneamente. Oltre questo limite, è possibile che solo un sottoinsieme di endpoint possa essere importato nei cluster in uso. Puoi esportare servizi diversi da sottoinsiemi di cluster diversi.

  • Il numero di pod dietro un singolo servizio: è sicuro mantenere al di sotto di 250 pod dietro un singolo servizio. Questa è la stessa limitazione dei servizi di un singolo cluster. Con carichi di lavoro relativamente statici e un numero ridotto di servizi multi-cluster, potrebbe essere possibile superare in modo significativo questo numero in migliaia di endpoint per servizio. Come con i servizi di cluster singoli, tutti gli endpoint vengono controllati da kube-proxy su ogni nodo. Quando si supera questo limite, soprattutto quando si esegue l'esportazione da più cluster contemporaneamente, potrebbero essere necessari nodi più grandi.

  • Il numero di servizi multi-cluster esportati contemporaneamente: ti consigliamo di esportare contemporaneamente non più di 50 porte di servizio univoche, identificate dal nome con spazio dei nomi di un servizio e dalle porte dichiarate. Ad esempio, l'esportazione di un servizio che espone le porte 80 e 443 verrà conteggiata in base a 2 delle 50 porte univoche per il servizio. I servizi con lo stesso nome con spazio dei nomi esportati da più cluster vengono conteggiati come un singolo servizio univoco. Il precedente servizio a 2 porte verrebbe conteggiato in due porte solo se fosse esportato da 5 cluster contemporaneamente. Ogni servizio multi-cluster viene conteggiato ai fini della quota di servizi di backend e ogni cluster o zona di esportazione crea un gruppo di endpoint di rete (NEG).

  • Tipi di servizio: MCS supporta solo ClusterSetIP e Headless Services. I servizi NodePort e LoadBalancer non sono supportati e potrebbero causare un comportamento imprevisto.

  • Utilizzo dell'agente IPmasq con MCS: MCS funziona come previsto quando utilizzi un intervallo IP di pod predefinito o non mascherato.

    Se utilizzi un intervallo IP di pod personalizzato o un agente IPmasq personalizzato ConfigMap, il traffico MCS può essere mascherato. Questo impedisce il funzionamento di MCS perché le regole firewall consentono il traffico solo dagli IP dei pod.

    Per evitare questo problema, devi utilizzare l'intervallo IP di pod predefinito o specificare tutti gli intervalli IP di pod nel campo nonMasqueradeCIDRs dell'agente IPmasq ConfigMap. Se utilizzi Autopilot o devi utilizzare un intervallo IP di pod non predefinito e non puoi specificare tutti gli intervalli IP dei pod in ConfigMap, devi utilizzare il criterio NAT in uscita per configurare l'accesso mascherato IP.

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 nel parco risorse in altri progetti, ma questi cluster non possono esportare lo stesso servizio nello stesso spazio dei nomi.

Risoluzione dei problemi

Le sezioni seguenti forniscono suggerimenti per la risoluzione dei problemi per MCS.

Visualizzazione del 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 l'uso.

  • WARNING: MCS sta eseguendo la riconciliazione della configurazione degli abbonamenti. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

  • FAILED: questo abbonamento non è stato aggiunto a MCS. Gli altri abbonamenti del parco risorse con un codice OK non sono interessati da questo abbonamento a FAILED. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

  • ERROR: questa iscrizione non contiene risorse. Gli altri abbonamenti del parco risorse con un codice OK non sono interessati da questo abbonamento a ERROR. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

Descrizioni in featureState

Una descrizione fornisce ulteriori informazioni sullo stato dell'appartenenza in MCS. Puoi trovare queste descrizioni nel campo state.description e vedere le seguenti:

  • Firewall successfully created: questo messaggio indica che la regola firewall del membro è stata creata e/o aggiornata. 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. Questa appartenenza può riscontrare problemi di aggiornamento e connessione ai nuovi servizi multi-cluster e delle iscrizioni aggiunte 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. Questa appartenenza deve essere annullata manualmente dalla registrazione 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 la presenza di errori interni StatusForbidden (403) e il codice dell'abbonamento è FAILED. Questo errore si verifica nei seguenti scenari:

    • Non hai abilitato le API necessarie nel progetto del membro.

      Se il cluster di membri si trova in un progetto separato da quello del parco risorse, consulta la pagina relativa alla configurazione tra progetti per assicurarti di aver completato tutti i passaggi necessari. Se hai completato tutti i passaggi, assicurati che le API seguenti siano abilitate nel progetto di registrazione con i comandi seguenti:

      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 o gkehub richiede maggiori autorizzazioni nel progetto del membro.

      Gli account di servizio mcsd e gkehub dovrebbero essere stati creati automaticamente nel progetto host del parco risorse con tutte le autorizzazioni richieste. Per verificare l'esistenza degli account di servizio, esegui questi 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 e gkehub.

  • 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. Lo stato dell'abbonamento è OK. La rete VPC di un cluster è definita dalla relativa rete di NetworkConfig. I servizi multi-cluster richiedono una rete piatta e questi VPC devono essere attivamente in peering affinché i servizi multi-cluster possano connettersi correttamente l'uno all'altro. Per scoprire di più, consulta Esempio di configurazione del peering di rete VPC.

  • 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'iscrizione è OK. Le appartenenze tra progetti sono definite come un cluster membro che non si trova nello stesso progetto del parco risorse. Per ulteriori informazioni, consulta la sezione sulla configurazione tra progetti.

  • Non-GKE clusters are currently not supported: questo messaggio ti ricorda che MCS supporta solo i cluster GKE. Impossibile aggiungere cluster non GKE a MCS. Lo stato dell'iscrizione è FAILED.

Problemi noti

Servizi MCS con più porte

Si è verificato 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 piano dati. Questo problema riguarda 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é una MCS con più porte.

MCS con VPC condiviso

Con l'attuale implementazione di MCS, se esegui il deployment di più di un parco risorse nello stesso VPC condiviso, i metadati vengono condivisi tra i parchi risorse. Quando un servizio viene creato in un parco risorse, i metadati dei servizi vengono esportati o importati in tutti gli altri parchi risorse che fanno parte dello stesso VPC condiviso e sono visibili all'utente.

Questo comportamento verrà risolto in una versione futura di MCS.

Il controllo di integrità utilizza la porta predefinita anziché la porta 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é la porta containerPort specificata.

Per evitare questo problema, utilizza valori numerici nel campo Servizio ports.targetPort e nel campo Deployment readinessProbe.httpGet.port anziché valori denominati.

Questo comportamento verrà risolto in una versione futura di MCS.

Passaggi successivi