Configurazione dei servizi multi-cluster

Questa pagina mostra come attivare e utilizzare i servizi multicluster (MCS). Per scoprire di più su come funziona MCS e sui suoi vantaggi, consulta Servizi multicluster.

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

Quando esporti un servizio con MCS, questo servizio diventa disponibile su tutti i cluster del tuo parco risorse.

Questa pagina spiega come configurare MCS con un singolo progetto. Per la configurazione di VPC condiviso per più progetti, segui la sezione Configurazione di servizi multi-cluster con VPC condiviso.

Google Cloud risorse 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 cluster di parchi risorse. In questo modo puoi connetterti ai servizi in esecuzione in altri cluster. Queste zone e questi 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 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 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 control plane per tenere traccia degli endpoint e della loro integrità nei cluster.

Requisiti

MCS ha i seguenti requisiti:

  • MCS supporta l'esportazione dei servizi solo dai cluster GKE nativi VPC su Google Cloud. Per ulteriori informazioni, consulta Creare 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. Se i cluster si trovano in reti separate e non connesse, le chiamate ai servizi external verranno bloccate. Ti consigliamo di attivare MCS nei progetti in cui i cluster si trovano nella stessa rete VPC.

    Per configurare MCS in un parco risorse tra progetti con un VPC condiviso, segui la sezione Configurazione dei servizi multi-cluster con VPC condiviso.

  • Sebbene un parco risorse possa includere più Google Cloud progetti e reti VPC, un singolo servizio multi-cluster deve essere esportato da un singolo progetto e da una singola rete VPC.

  • MCS non è supportato con i criteri di rete.

  • I cluster devono avere il componente aggiuntivo HttpLoadBalancing abilitato. Assicurati che il plug-inHttpLoadBalancing sia attivo. Il componente aggiuntivo HttpLoadBalancing è attivo per impostazione predefinita e non deve essere disattivato.

Prezzi

I servizi multi-cluster sono inclusi nella commissione per la gestione dei cluster GKE e non hanno costi aggiuntivi per l'utilizzo. Devi abilitare l'API Traffic Director, ma MCS non comporta costi per gli endpoint Cloud Service Mesh. Le licenze GKE Enterprise non sono obbligatorie per utilizzare MCS.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  1. Installa Google Cloud SDK.

  2. Attiva l'API Google Kubernetes Engine:

    Attiva l'API Google Kubernetes Engine

  3. Connetti le tue reti VPC con il peering di reti VPC, Cloud Interconnect o Cloud VPN.

  4. Abilita le API MCS, fleet (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 tuoi cluster in un parco risorse.

Attivazione di MCS nel progetto

MCS richiede che i cluster GKE partecipanti siano registrati nella stessa flotta. 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 a un parco risorse, non è necessario attivare 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 tutti i cluster registrati al parco risorse comporteranno addebiti 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.

Attivazione di MCS sul 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 tuoi cluster in un parco risorse. Questo è il tuo progetto host del parco risorse.

    L'attivazione dei servizi multi-cluster nel progetto host del parco risorse crea o garantisce l'esistenza dell'account di servizio service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com.

  2. 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 Workload Identity per GKE, devi registrare il cluster con un Google Cloud account di servizio 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 il seguente 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 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.

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

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto host del parco risorse.
    • PROJECT_NUMBER: il numero del progetto del parco risorse host.

  4. Assicurati che ogni cluster del 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 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:

Utilizzo di MCS

Le sezioni seguenti mostrano come utilizzare MCS. MCS utilizza l'API Kubernetes per i servizi multi-cluster.

Registrazione di un servizio per l'esportazione

Per registrare un servizio per l'esportazione in altri cluster all'interno 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 del tuo parco risorse.

  2. Crea la risorsa ServiceExport eseguendo il seguente 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 degli endpoint successive vengono eseguite immediatamente.

Puoi esportare lo stesso servizio da più cluster per creare un unico endpoint di servizio multi-cluster altamente disponibile con distribuzione del traffico tra i 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 dell'elevata probabilità di conflitti di nomi involontari e del conseguente raggruppamento involontario. 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 risolve 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 e NAMESPACE: i valori che definisci nell'oggetto ServiceExport.

Per i servizi ClusterSetIP, il dominio si risolve in 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: 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 di un'importazione di servizi. 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: 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 dell'annotazione net.gke.io/derived-service nell'oggetto ServiceImport.
  • NAMESPACE: lo spazio dei nomi dell'oggetto ServiceExport.

Puoi scoprire di più sullo stato di salute degli endpoint utilizzando la dashboard Cloud Service Mesh nella Google Cloud console.

Per i servizi headless, il dominio si risolve nell'elenco degli indirizzi IP degli endpoint nei cluster di esportazione. Ogni pod di backend con un nome host è anche indirizzabile in modo indipendente con un nome di dominio del seguente tipo:

 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 posizione è una delle regioni o delle zone in cui si trova il pod, ad esempio us-central1.
  • HOSTNAME: il nome host del pod.

Puoi anche indirizzare 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

Disattivazione di MCS

Per disattivare MCS, completa i seguenti passaggi:

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

  2. Verifica che ServiceExport scompaia dall'elenco dopo 30 minuti.

  3. Annullare la registrazione dei cluster dal parco risorse se non devono essere registrati 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. Disattiva 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

Numero di cluster, pod e porte di servizio

I seguenti limiti non vengono applicati in modo forzato e, in alcuni casi, puoi superarli a seconda del carico nei tuoi cluster o nel tuo progetto e del tasso di abbandono degli endpoint. Se superi questi limiti, potresti riscontrare problemi di prestazioni.

In Kubernetes, un servizio è identificato in modo univoco dal nome e dallo spazio dei nomi a cui appartiene. Questa coppia di nome e spazio dei nomi è chiamata nome con spazio dei nomi.

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

  • Numero di pod dietro un singolo servizio: è sicuro se non superi i 250 pod dietro un singolo servizio. Si tratta della stessa limitazione dei servizi a singolo cluster. Con carichi di lavoro relativamente statici e un numero ridotto di servizi multi-cluster, potrebbe essere possibile superare notevolmente questo numero fino a migliaia di endpoint per servizio. Come per i servizi di singoli cluster, tutti gli endpoint vengono monitorati da kube-proxy su ogni nodo. Se superi questo limite, soprattutto se esporti da più cluster contemporaneamente, potrebbero essere necessari nodi di dimensioni maggiori.

  • Numero di servizi multi-cluster esportati contemporaneamente: consigliamo di esportare contemporaneamente non più di 250 porte di servizio univoche.

    Una porta di servizio univoca è identificata da un nome nello spazio dei nomi e da un numero di porta, ovvero da una tupla (nome, spazio dei nomi, numero di porta). Ciò significa che:

    • I servizi con lo stesso nome e la stessa porta nello stesso spazio dei nomi, esportati da più cluster, vengono conteggiati come una singola porta di servizio univoca.

    • Due servizi con lo stesso nome e la stessa porta, ma spazi dei nomi diversi, ad esempio (name, ns1, port-80) e (name, ns2, port-80) sono due porte di servizio diverse, che vengono conteggiate come due dei 250 limiti di porte di servizio univoche.

    • Un servizio esportato che espone due porte, 80 e 443, viene conteggiato per due dei 250 limiti di porte dei servizi univoci, indipendentemente dal numero di cluster nel parco che esportano contemporaneamente questo servizio.

    Ogni servizio multi-cluster viene conteggiato ai fini della quota dei servizi di backend e ogni zona di ogni cluster di esportazione crea un gruppo di endpoint di rete (NEG). L'aumento di queste quote non modifica il limite indicato per il conteggio totale delle porte di servizio univoche.

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 di IPmasq Agent con MCS

MCS funziona come previsto quando utilizzi un intervallo IP del pod predefinito o di altro tipo non mascherato.

Se utilizzi un intervallo IP del pod personalizzato o un ConfigMap dell'agente IPmasq personalizzato, il traffico MCS può essere mascherato. Ciò impedisce il funzionamento di MCS perché le regole firewall consentono solo il traffico dagli IP del 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 utilizzi Autopilot o devi utilizzare un intervallo IP del pod non predefinito e non puoi specificare tutti gli intervalli IP del pod nel ConfigMap, devi utilizzare il criterio NAT in uscita per configurare l'accesso mascherato degli IP.

Riutilizzo dei 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.

Questo vale sia all'interno di un servizio Kubernetes sia a tutti i servizi Kubernetes 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 sezioni seguenti forniscono suggerimenti per la risoluzione dei problemi relativi a MCS.

Visualizzazione dello stato della funzionalità MCS

La visualizzazione dello stato della risorsa Feature può aiutarti a verificare se MCS è stato configurato correttamente. Puoi visualizzare lo stato con 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: {}

È costituito, tra le altre informazioni, dallo stato complessivo della funzionalità in resourceState e dallo stato dei singoli abbonamenti in membershipStates.

Se hai attivato la funzionalità MCS in base alle istruzioni per l'attivazione di MCS nel tuo cluster GKE, ma il valore di resourceState.state non è ACTIVE, contatta l'assistenza.

Lo stato di ogni appartenenza è costituito dal relativo percorso e dal campo state. Quest'ultimo contiene code e description, che sono utili per la risoluzione dei problemi.

Codici negli stati dell'abbonamento

Un codice, rappresentato dal campo state.code, indica lo stato generale del membro in relazione al programma MCS. Esistono quattro valori possibili:

  • OK: l'abbonamento è stato aggiunto correttamente a MCS ed è pronto per essere utilizzato.

  • WARNING: MCS è in fase di riconciliazione della configurazione dell'abbonamento. Il campo della descrizione può fornire ulteriori informazioni su cosa ha causato questo codice.

  • FAILED: questo abbonamento non è stato aggiunto a MCS. Gli altri abbonamenti nel parco con un codice OK non sono interessati da questo abbonamento FAILED. Il campo della descrizione può fornire ulteriori informazioni su cosa ha causato questo codice.

  • ERROR: in questo abbonamento mancano delle risorse. Gli altri abbonamenti nel parco con un codice OK non sono interessati da questo abbonamento ERROR. Il campo della descrizione può fornire ulteriori informazioni su cosa ha causato questo codice.

Descrizioni negli stati dell'abbonamento

Per visualizzare informazioni sullo stato dell'abbonamento in MCS, controlla il state.description campo. Questo campo fornisce informazioni sulla configurazione del progetto e dell'hub, nonché sullo stato di salute del parco risorse e degli abbonamenti. Per visualizzare informazioni sui singoli servizi e sulla loro configurazione, consulta il campo Status.Conditions nell'oggetto ServiceExport, consulta la sezione Esaminare ServiceExport.

Il campo state.description contiene le seguenti informazioni:

  • 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. Questo abbonamento potrebbe riscontrare problemi di aggiornamento e connessione ai nuovi servizi e abbonamenti multi-cluster aggiunti mentre la regola del 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 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 diverso dal parco, 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 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 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 richieste. 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 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 rete di NetworkConfig. I servizi multi-cluster richiedono una rete piatta e questi VPC devono essere in peering attivo affinché i servizi multi-cluster si connettano correttamente tra loro. 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 messaggio ti ricorda che MCS supporta solo i cluster GKE. I cluster non GKE non possono essere aggiunti a MCS. Lo stato dell'abbonamento è FAILED.

Esamina ServiceExport

Per visualizzare lo stato di un singolo servizio e i potenziali errori, controlla il campo Status.Conditions nella risorsa ServiceExport per quel servizio:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

L'output è simile al seguente:

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

Quando il controller MCS rileva una risorsa ServiceExport, aggiunge le seguenti condizioni al campo Status.Conditions:

  • Initialized: True se il controller MCS ha rilevato e tentato di mediare il servizio rappresentato da ServiceExport.

  • Exported: True se il servizio rappresentato dall'ServiceExport è stato convalidato correttamente.

Ogni condizione contiene campi obbligatori Type, Status e LastTransitionTime. Quando il controller MCS riconcilia e convalida il servizio, il campo Status per la condizione corrispondente passa da False a True.

Errori

Se si verifica un errore durante la convalida, il controller imposta il campo Status della condizione Exported su False e aggiunge un campo Reason e un campo Message con ulteriori informazioni sull'errore. Il campo Reason può avere uno dei seguenti valori:

  • NoMatchingService: non è stato trovato alcun servizio corrispondente al nome e allo spazio dei nomi del servizio ServiceExport nel cluster specificato.
    Verifica se il servizio Kubernetes che intendi esportare esiste nello stesso cluster. Verifica che il nome e lo spazio dei nomi di entrambe le risorse (Service e ServiceExport) corrispondano esattamente.

  • Conflict: esiste già un servizio esportato con lo stesso nome e lo stesso spazio dei nomi che non corrisponde a quello esportato da questo ServiceExport o che viene esportato da una rete o un progetto diverso, il che non è consentito. Consulta le limitazioni.
    Esamina il campo Message per i dettagli e consulta la sezione Limitazioni, se necessario. Assicurati che il nome e lo spazio dei nomi di Service e ServiceExport corrispondano e che tutte le risorse siano create nella stessa rete e/o nello stesso progetto.

  • ReadinessProbeError: è configurato un readinessProbe su un contenitore in un pod che supporta il servizio per il quale TimeoutSeconds > PeriodSeconds. In GKE, readinessProbes vengono tradotti in HealthChecks e devono essere conformi alle stesse restrizioni. Consulta checkIntervalSec e timeoutSec per HealthChecks. Il motivo di questa limitazione è evitare che i controlli successivi si sovrappongano.
    Modifica i parametri di readinessProbe in base al riferimento. È importante correggere questo errore per ogni servizio del parco risorse. Per ulteriori spiegazioni, consulta la sezione Problemi noti.

  • ServiceError: si è verificato un errore durante il recupero del servizio corrispondente.
    In genere questo errore è correlato a un problema dell'infrastruttura Google Cloud. Contatta l'assistenza Google Cloud se il problema persiste.

  • PodsError: si è verificato un errore durante il recupero del pod o dei pod di backend
    In genere, questo errore è correlato a un problema dell'infrastruttura Google Cloud. Contatta l'assistenza Google Cloud se il problema persiste.

  • EndpointsError: si è verificato un errore durante l'aggregazione di endpoint per un servizio headless
    In genere, questo errore è correlato a un problema dell'infrastruttura Google Cloud. Contatta l'assistenza Google Cloud se il problema persiste.

Il campo Message fornisce un contesto aggiuntivo per l'errore.

Problemi comuni relativi alle autorizzazioni

  • API necessarie non abilitate nel progetto.

    Assicurati di aver attivato le API richieste come indicato nella sezione Prima di iniziare.

    Per un parco multi-project, segui la sezione Abilita le API richieste appropriata in Configurazione dei servizi multi-cluster con VPC condiviso.

  • L'account di servizio mcsd o gkehub non dispone di autorizzazioni sufficienti

    Per una configurazione di un singolo progetto, tutte le autorizzazioni necessarie vengono concesse automaticamente agli account di servizio creati automaticamente da GKE Hub e MCS.

    Per un parco tra progetti, devi creare associazioni IAM aggiuntive. Segui la sezione Creare associazioni IAM appropriata in Configurazione dei servizi multi-cluster con VPC condiviso.

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

Questo vale sia all'interno di un servizio Kubernetes sia a tutti i servizi Kubernetes per un servizio MCS.

MCS con VPC condiviso

Con l'attuale implementazione di MCS, se esegui il deployment di più parchi risorse nella stessa VPC condiviso, i metadati vengono 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.

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 valori numerici nel campo Servizioports.targetPort e nel campo DeploymentreadinessProbe.httpGet.port anziché valori con nome.

Il controllo di idoneità non valido per un singolo servizio interrompe altri servizi

Esiste un potenziale errore di configurazione di readinessProbe descritto in Esaminare ServiceExports. Con l'attuale implementazione di MCS, questo errore, se introdotto per un singolo servizio esportato, può impedire la sincronizzazione di alcuni o di tutti gli altri servizi nel parco.

È importante mantenere in buono stato le configurazioni di ogni servizio. Se un servizio MCS non viene aggiornato, assicurati che nessuno dei ServiceExports in uno dei cluster in uno dei namespace riporti ReadinessProbeError come motivo per cui la condizione di stato Exported è False. Consulta Esaminare ServiceExports per scoprire come controllare le condizioni.

Passaggi successivi