Configurazione dei servizi multi-cluster

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

La funzionalità MCS di Google Kubernetes Engine (GKE) estende la copertura del servizio Kubernetes oltre il limite del cluster e ti consente di scoprire e richiamare i servizi in più cluster GKE. Puoi esportare un sottoinsieme di Servizi esistenti o nuovi.

Quando esporti un servizio con MCS, questo servizio è disponibile in tutti i cluster del 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 Cloud DNS per ogni servizio esportato nei tuoi cluster del parco risorse. Ciò ti consente di connetterti ai servizi in esecuzione in altri cluster. Queste zone e record vengono creati, letti, aggiornati ed eliminati in base ai Servizi che scegli di esportare nei cluster.

  • Regole firewall: MCS configura le regole firewall che consentono ai pod di comunicare tra loro nei cluster all'interno del tuo 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 create 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 del loro integrità nei vari cluster.

Requisiti

MCS prevede i seguenti requisiti:

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

  • 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 oltrepassare il confine della rete.

  • Mentre un parco risorse può includere più progetti Google Cloud e reti VPC, un singolo servizio multi-cluster deve essere esportato da un singolo progetto e un'unica 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 prevede addebiti per l'endpoint di Cloud Service Mesh. Per usare MCS non sono necessarie licenze di GKE Enterprise.

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, Cloud Service Mesh 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 del progetto 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 abilitata la funzionalità MCS per un parco risorse, qualsiasi cluster può esportare i servizi tra i cluster nel parco risorse.

Sebbene MCS richieda la registrazione in un parco risorse, non richiede l'abilitazione della 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 GKE Enterprise, tutti i cluster registrati nel parco risorse del progetto vengono addebitati 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 l'intera piattaforma GKE Enterprise e tutti i cluster registrati nel parco risorse subiranno gli 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 nel 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 del progetto in cui prevedi di registrare i cluster in un parco risorse. Questo è il tuo progetto host del parco risorse.

  2. Registra i tuoi 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 abiliti 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 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 dell'appartenenza che scegli per rappresentare in modo univoco il cluster nel parco risorse. 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 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.

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

  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 di 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 gli aggiornamenti degli endpoint da Cloud Service Mesh, quindi per abilitare 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 usare l'account di servizio predefinito di Compute Engine o il tuo account di servizio nodo:

Utilizzo di MCS

Le seguenti sezioni mostrano 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 del tuo parco risorse, completa i seguenti 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 nel cluster che vuoi esportare in altri cluster all'interno del tuo parco risorse.

  2. Crea la risorsa ServiceExport eseguendo questo comando:

    kubectl apply -f export.yaml

La sincronizzazione iniziale del servizio con i cluster registrati nel parco risorse richiede circa cinque minuti. Dopo l'esportazione di un servizio, le successive sincronizzazioni 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 spazio dei nomi, assicurati di volerli raggruppare in questo modo. Consigliamo di non esportare i servizi negli spazi dei nomi default e kube-system a causa dell'elevata probabilità di conflitti di nomi involontari e del conseguente raggruppamento non intenzionale. Se esporti più di cinque servizi con lo stesso nome e 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 "A" del DNS.

Dopo aver creato un oggetto ServiceExport, il seguente nome di dominio viene risolto 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 criterio 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 durante l'importazione di un Service in un cluster. Indagando questo oggetto puoi monitorare l'avanzamento di un'importazione di 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

Quindi, 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 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.

Per ulteriori informazioni sullo stato di integrità degli endpoint, puoi utilizzare la dashboard di Cloud Service Mesh nella console Google Cloud.

Per i servizi headless, il dominio si risolve nell'elenco di indirizzi IP degli endpoint nei cluster in esportazione. Ogni pod di backend con un nome host è inoltre raggiungibile 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 oppure la loro località è 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 abbonamento globale, utilizzando un nome di dominio nel seguente formato:

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

Disabilitazione di MCS

Per disattivare MCS, completa i seguenti passaggi:

  1. Per ogni cluster nel 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. Verifica che ServiceExport scompaia dall'elenco entro 30 minuti.

  3. Annulla la registrazione dei cluster dal parco risorse se non è necessario registrarli per un altro scopo.

  4. Disattiva la funzionalità multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto in cui hai registrato i cluster.

  5. Disabilita l'API per MCS:

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto in cui hai registrato i cluster.

Limitazioni

I seguenti limiti non vengono applicati e, in alcuni casi, puoi superarli a seconda del carico nei cluster o nel progetto e della percentuale di abbandono degli endpoint. Tuttavia, potresti riscontrare problemi di prestazioni quando queste limitazioni vengono superate.

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

  • Il numero di pod dietro un singolo servizio: è sicuro mantenere al di sotto di 250 pod dietro un singolo servizio. Questa è la stessa limitazione prevista dai servizi a cluster singolo. Con carichi di lavoro relativamente statici e un numero limitato di servizi multi-cluster, potrebbe essere possibile superare in modo significativo questo numero in migliaia di endpoint per servizio. Come per i servizi a singolo cluster, tutti gli endpoint vengono controllati da kube-proxy su ogni nodo. Quando si supera questo limite, soprattutto quando si esporta contemporaneamente da più cluster, 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 lo spazio dei nomi di un servizio e dalle porte dichiarate. Ad esempio, l'esportazione di un servizio che espone le porte 80 e 443 viene conteggiata con 2 dei 50 limiti di porte del servizio univoci. I servizi con lo stesso nome con spazio dei nomi esportati da più cluster vengono conteggiati come un unico servizio univoco. Il servizio a 2 porte citato in precedenza verrebbe conteggiato con 2 porte solo se viene esportato da 5 cluster contemporaneamente. Ciascun servizio multi-cluster viene conteggiato ai fini della quota dei 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 portare a un comportamento imprevisto.

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

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

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

MCS con cluster in più progetti

Non puoi esportare un servizio se il servizio è già esportato da altri cluster in un progetto diverso nel parco risorse con lo stesso nome e spazio dei nomi. Puoi accedere al servizio in altri cluster del parco risorse in altri progetti, ma tali 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 per MCS.

Visualizzazione di featureState

Visualizzare lo stato della funzionalità può aiutarti a verificare se MCS è stata configurata 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. I codici possibili sono tre:

  • OK: l'abbonamento è stato aggiunto a MCS ed è pronto per l'uso.

  • WARNING: MCS sta per riconciliare la configurazione dell'abbonamento. Il campo della descrizione può fornire ulteriori informazioni sulla causa del codice.

  • FAILED: questa iscrizione non è stata aggiunta a MCS. Gli altri membri 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 del codice.

  • ERROR: in questo abbonamento mancano alcune risorse. Gli altri membri 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 del codice.

Descrizioni in featureState

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

  • Firewall successfully created: questo messaggio indica che la regola firewall del membro è stata creata e o aggiornata correttamente. 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ò causare problemi di aggiornamento e connessione ai nuovi servizi multi-cluster e alle iscrizioni aggiunte mentre la regola firewall è in attesa.

  • GKE Cluster missing: questo messaggio indica che il cluster GKE registrato non è disponibile o è stato eliminato. Il codice dell'abbonamento è ERROR. È necessario annullare manualmente la registrazione al 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 StatusForbidden (403) interni 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 membro si trova in un progetto separato da quello del parco risorse, consulta la configurazione tra progetti per assicurarti di aver completato tutti i passaggi necessari. Se hai completato tutti i passaggi, assicurati che le seguenti API 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 del progetto in cui hai registrato i cluster.

    • L'account di servizio mcsd o gkehub richiede più 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 necessarie. Per verificare che gli account di servizio esistano, 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. Stato abbonamento è 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 con peering attivo per consentire ai servizi multi-cluster di connettersi correttamente tra loro. Per saperne 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 multiprogetto richiedono passaggi di configurazione aggiuntivi. Stato elenco: OK. Le appartenenze tra progetti sono un cluster di membri 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

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 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ù sistemi MCS con una singola porta anziché un 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 del servizio 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 prossima release 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 valore containerPort specificato.

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

Questo comportamento verrà risolto in una prossima release di MCS.

Passaggi successivi