Configurazione dei servizi multi-cluster

Questo documento mostra come attivare e utilizzare i servizi multi-cluster (MCS). Utilizzando MCS, puoi scoprire e richiamare i servizi Kubernetes in più cluster Google Kubernetes Engine (GKE). MCS ti aiuta a creare applicazioni ad alta affidabilità e distribuite geograficamente, rendendo i tuoi servizi resilienti e scalabili. Quando esporti un servizio con MCS, questo è disponibile in tutti i cluster del tuo parco risorse.

Questo documento è rivolto ai network engineer che gestiscono il networking tra i cluster e i team. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui si fa riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Per saperne di più sul funzionamento di MCS e sui suoi vantaggi, consulta Servizi multi-cluster.

RisorseGoogle Cloud gestite da MCS

MCS gestisce i seguenti componenti di Google Cloud:

  • Cloud DNS: MCS configura zone e record Cloud DNS per ogni servizio esportato nei cluster del parco 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 tra i cluster.

  • Regole firewall: MCS configura regole firewall che consentono ai pod di comunicare tra loro tra i 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 consentire la comunicazione tra i pod all'interno di un cluster GKE.

  • Control plane di Traffic Director: MCS utilizza il control plane di Traffic Director per monitorare gli endpoint e il loro stato nei cluster.

Requisiti

MCS ha i seguenti requisiti:

  • Affinché MCS funzioni correttamente, GKE esegue il deployment del pod gke-mcs-importer sui tuoi nodi con autorizzazioni RBAC elevate. Queste autorizzazioni consentono all'importatore di gestire endpoint, servizi e ServiceImport per propagare i metadati dei servizi tra i cluster del tuo parco risorse. L'importatore non dispone dell'autorizzazione per visualizzare o modificare i tuoi deployment.

  • MCS supporta solo l'esportazione di servizi da cluster GKE nativi di VPC su Google Cloud. Per saperne di più, consulta Creazione di un cluster nativo di VPC. Non puoi utilizzare 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 in reti VPC condiviso. Se i cluster si trovano in reti separate e non connesse, le chiamate ai servizi esterni verranno bloccate. Ti consigliamo di abilitare MCS nei progetti in cui i cluster si trovano nella stessa rete VPC. Tuttavia, un parco risorse non può contenere cluster di più di una rete VPC condiviso.

    Per configurare MCS su un parco risorse tra progetti con un VPC condiviso, segui la procedura descritta in Configurazione di servizi multi-cluster con VPC condiviso.

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

  • MCS non è supportato con le policy di rete.

  • I cluster devono avere il componente aggiuntivo HttpLoadBalancing abilitato. Assicurati che il componente aggiuntivo HttpLoadBalancing sia abilitato. Il componente aggiuntivo HttpLoadBalancing è abilitato per impostazione predefinita e non deve essere disabilitato.

Prezzi

I servizi multi-cluster sono inclusi nella tariffa di gestione dei cluster GKE e non prevedono costi aggiuntivi per l'utilizzo. Devi abilitare l'API Traffic Director, ma MCS non comporta addebiti per gli endpoint Cloud Service Mesh.

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. Connetti le tue reti VPC con il peering di rete VPC, Cloud Interconnect o Cloud VPN.

  4. Abilita le API MCS, parco risorse (hub), Resource Manager, Traffic Director, Cloud DNS e Connect Gateway:

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    connectgateway.googleapis.com \
    --project=PROJECT_ID

    Sostituisci PROJECT_ID con l'ID 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 può esportare i servizi tra i cluster del parco risorse.

Abilitazione 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 progetto in cui prevedi di registrare i 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 del account di servizio service-PROJECT_NUMBER@gcp-sa-mcsd..

  2. Registra i cluster GKE nel parco risorse. Ti consigliamo vivamente di registrare il cluster con Workload Identity Federation for GKE abilitato. Se non abiliti Workload Identity Federation for GKE, devi registrare il cluster con un service account Google Cloud per l'autenticazione e completare i passaggi aggiuntivi descritti in Autenticazione dei service account.

    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 è il 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) richieste per MCS Importer:

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto del progetto host del parco risorse.
    • PROJECT_NUMBER: il numero 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 Risoluzione dei problemi.

Autenticazione dei service account

Se hai registrato i cluster GKE in un parco risorse utilizzando un service account, devi eseguire ulteriori passaggi per autenticare il account di servizio. MCS esegue il deployment di un componente denominato gke-mcs-importer. Questo componente riceve gli aggiornamenti degli endpoint dal control plane di Traffic Director, pertanto, per attivare MCS, devi concedere al tuo service account l'autorizzazione per leggere le informazioni da Cloud Service Mesh.

Quando utilizzi un account di servizio, puoi utilizzare il 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 dei servizi multi-cluster di 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 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 allo spazio dei nomi del servizio che stai esportando.
    • SERVICE_EXPORT_NAME: il nome di un servizio nel tuo 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

L'esportazione iniziale del servizio richiede circa cinque minuti per la sincronizzazione con i cluster registrati nel 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 endpoint di servizio multi-cluster ad alta affidabilità con distribuzione del traffico tra i cluster. Prima di esportare servizi con lo stesso nome e spazio dei nomi, assicurati che siano 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 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 tra cluster

MCS supporta solo i servizi ClusterSetIP e headless. Sono disponibili solo i record DNS "A".

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 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 EndpointSlice nell'ambito dell'importazione di un servizio in un cluster. Esaminando questo oggetto puoi monitorare l'avanzamento di un'importazione di servizi.

Per trovare il nome dell'oggetto EndpointSlice, 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: SERVICE-EXPORT-TARGET

Successivamente, cerca l'oggetto EndpointSlice per verificare se MCS ha già propagato gli endpoint al cluster di importazione. L'oggetto EndpointSlice 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 endpointslice -l kubernetes.io/service-name=DERIVED_SERVICE_NAME -n NAMESPACE

Sostituisci quanto segue:

  • DERIVED_SERVICE_NAME: il valore dell'annotazione net.gke.io/derived-service sull'oggetto ServiceImport.
  • NAMESPACE: lo spazio dei nomi dell'oggetto ServiceExport.

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

Per i servizi headless, il dominio viene risolto nell'elenco di 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 nel seguente formato:

 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à della membership. Le membership sono global o la loro località è una delle regioni o 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'appartenenza 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 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.

    La rimozione completa di tutti i ServiceExports può richiedere fino a un'ora.

  2. Annulla la registrazione dei cluster dal parco risorse se non è necessario che siano 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.

    Verifica l'eliminazione

    Quando disattivi la funzionalità, un messaggio di operazione riuscita conferma l'eliminazione.

    Se visualizzi il seguente messaggio, la funzionalità è disattivata:

    Waiting for Feature Multi-cluster Services to be deleted...done.

    Risolvi gli errori di eliminazione

    Se non elimini tutte le risorse ServiceExport prima di disattivare MCS o se l'eliminazione di ServiceExports o delle risorse gestite non è stata completata, potresti visualizzare un messaggio di errore.

    Il seguente messaggio indica che le risorse associate esistono ancora:

    Feature has associated resources that should be cleaned up before
deletion. Check the Feature state details for more information. This check
can be overridden by setting force=true.

    Per risolvere questo errore, controlla lo stato della funzionalità:

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

    Nell'output, controlla il campo description. Esistono due possibili casi:

    1. ServiceExports non vengono rimossi.

      Il messaggio indica che nel parco risorse esistono ServiceExport risorse:

      There are N ServiceExport in the Fleet.

      Assicurati di eliminare tutte le risorse ServiceExport. Finché tutti i ServiceExports non vengono eliminati completamente, la disattivazione di MCS continuerà a non riuscire.

      Attendi un'ora ed esegui di nuovo il comando:

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

    2. Le risorse gestite non vengono rimosse.

      Il messaggio indica che le risorse sono in fase di rimozione:

      There are no ServiceExports in the Fleet. Managed resources are in the
process of being removed. See
https://docs.cloud.google.com/kubernetes-engine/docs/how-to/multi-cluster-services#troubleshoot
for more information.

      Il backend MCS deve finalizzare il processo di pulizia. Occasionalmente, questo processo deve essere riavviato, il che aggiunge un ritardo fino a tre ore. Finché tutte le risorse gestite non vengono eliminate completamente, la disattivazione di MCS continuerà a non riuscire.

      Attendi tre ore ed esegui di nuovo il comando:

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

    Forza la disattivazione della funzionalità

    Puoi forzare la disattivazione della funzionalità multiclusterservicediscovery.

    Per forzare la disattivazione della funzionalità, esegui questo comando:

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

  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

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 cluster o nel progetto e della frequenza di abbandono degli endpoint. Se questi limiti vengono superati, potresti riscontrare problemi di prestazioni.

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

  • Esportazione di cluster: un singolo servizio, identificato da un nome con spazio 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 di consumo. Puoi esportare servizi diversi da sottoinsiemi di cluster diversi.

  • Il numero di pod dietro un singolo servizio: è sicuro se mantieni un numero inferiore a 250 pod dietro un singolo servizio. Con workload relativamente statici e un numero ridotto di servizi multi-cluster, potrebbe essere possibile superare in modo significativo questo numero fino a migliaia di endpoint per servizio. Come per i servizi a cluster singolo, tutti gli endpoint vengono monitorati da kube-proxy su ogni nodo. Se superi questo limite, soprattutto quando esporti da più cluster contemporaneamente, potrebbero essere necessari nodi più grandi.

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

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

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

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

    • Un servizio esportato che espone due porte 80 e 443 viene conteggiato come due del limite di 250 porte di servizio univoche, indipendentemente dal numero di cluster nel parco risorse 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 numero totale di porte di servizio univoche.

Tipi di servizi

MCS supporta solo i servizi ClusterSetIP e headless. 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 di IP dei pod predefinito o non mascherato.

Se utilizzi un intervallo IP dei 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 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 di 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 la policy NAT in uscita per configurare l'IP masquerading.

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 per tutti i servizi Kubernetes per un servizio MCS.

MCS con cluster in più progetti

Non puoi esportare un servizio se questo è già stato 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 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 delle singole membership in membershipStates.

Se hai attivato la funzionalità MCS seguendo le istruzioni riportate in Attivazione di MCS sul cluster GKE, ma il valore di resourceState.state non è ACTIVE, contatta l'assistenza.

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

Codici negli stati di appartenenza

Un codice, rappresentato dal campo state.code, indica lo stato generale del membro in relazione a MCS. I valori possibili sono quattro:

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

  • WARNING: MCS sta riconciliando la configurazione dell'appartenenza. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

  • FAILED: questo abbonamento non è stato aggiunto a MCS. Le altre membership nel parco risorse con un codice OK non sono interessate da questa membership FAILED. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

  • ERROR: a questa membership mancano delle risorse. Le altre membership nel parco risorse con un codice OK non sono interessate da questa membership ERROR. Il campo della descrizione può fornire ulteriori informazioni sulla causa di questo codice.

Descrizioni degli stati di iscrizione

Per visualizzare le informazioni sullo stato dell'appartenenza in MCS, controlla il campo state.description. Questo campo fornisce informazioni sulla configurazione del progetto e dell'hub e sullo stato di integrità del parco risorse e delle relative appartenenze. Per visualizzare informazioni sui singoli servizi e sulla loro configurazione, consulta il campo Status.Conditions nell'oggetto ServiceExport, vedi la sezione Esame di 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. Questa membership potrebbe riscontrare problemi di aggiornamento e connessione a nuovi servizi multi-cluster e membership aggiunti 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. La registrazione di questa appartenenza deve essere annullata manualmente 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 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 di appartenenza si trova in un progetto separato rispetto al 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 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.

    • ILmcsd Ogkehub L'account di servizio richiede maggiori autorizzazioni nel progetto del membro.

      I service account mcsd e gkehub dovrebbero essere stati creati automaticamente nel progetto host del parco risorse con tutte le autorizzazioni richieste. Per verificare l'esistenza dei service account, 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 dei service account 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 di abbonato è 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 possano connettersi correttamente tra loro. Per saperne di più, consulta Esegui 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 di abbonato è OK. Le appartenenze tra progetti sono definite come un cluster di appartenenza che non si trova nello stesso progetto del parco risorse. Per saperne di più, 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 di abbonato è FAILED.

Esame di 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 riconciliare il servizio rappresentato da ServiceExport.

  • Exported: Vero se il Servizio rappresentato dalServiceExport è stato convalidato con successo.

Ogni condizione contiene i campi obbligatori Type, Status e LastTransitionTime. Man mano che il controller MCS riconcilia e convalida il servizio, il campo Status per la condizione corrispondente cambia 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 di ServiceExport nel cluster specificato.
    Verifica se il servizio Kubernetes che intendi esportare esiste nello stesso cluster. Verifica se il nome e lo spazio dei nomi di entrambe le risorse (Service e ServiceExport) corrispondono 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 Limitazioni.
    Controlla 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 container in un pod che supporta il servizio. Kubernetes ReadinessProbes vengono tradotti in Google cloud HealthChecks e devono rispettare le stesse limitazioni.

    Nota: MCS utilizza una porta definita nell'impostazione readinessProbe di un container come porta autorevole per i controlli di integrità propagati al control plane di Traffic Director. MCS seleziona il primo container nel pod aggregato meno recente che espone la targetPort del servizio, anche se la readinessProbe di quel container viene pubblicata su una porta diversa. Se il servizio targetPort è diverso dalla porta readinessProbe, assicurati che la porta readinessProbe sia accessibile e configurata correttamente, poiché questa porta determina lo stato di integrità del servizio in Cloud Service Mesh.

    Ecco come i campi del controllo di idoneità si allineano ai parametri del controllo di integrità:

    • PeriodSeconds corrisponde a CheckInterval
    • TimeoutSeconds corrisponde a Timeout
    • SuccessThreshold corrisponde a HealthyThreshold
    • FailureThreshold corrisponde a UnhealthyThreshold

    Per allineare ReadinessProbes ai vincoli di HealthCheck, MCS implementa quanto segue:

    • PeriodSeconds e TimeoutSeconds hanno un limite massimo di 300 secondi; i valori che superano questo limite generano un errore.
    • SuccessThreshold e FailureThreshold hanno un limite massimo di 10 secondi; i valori che superano questo limite generano un errore.
    • Viene segnalato un errore e la creazione delle risorse (potenzialmente tutte le risorse) non va a buon fine se TimeoutSeconds è maggiore di PeriodSeconds.

    La logica alla base di queste limitazioni è quella di evitare problemi di scalabilità, la sovrapposizione di probe successivi, la lentezza dei controlli di integrità/idoneità e così via. Modifica i parametri di readinessProbe in base alle convalide precedenti. È importante correggere questi errori per ogni servizio del parco risorse. Per ulteriori spiegazioni, consulta Problemi noti.

  • ServiceError: si è verificato un errore durante il recupero del servizio corrispondente.
    Questo errore è solitamente correlato a un problema dell'infrastruttura Google Cloud. Se il problema persiste, contatta l'assistenza Google Cloud.

  • PodsError: si è verificato un errore durante il recupero del pod o dei pod di backend
    Questo errore è solitamente correlato a un problema dell'infrastruttura Google Cloud. Se il problema persiste, contatta l'assistenza Google Cloud.

  • EndpointsError: si è verificato un errore durante l'aggregazione degli endpoint per un servizio headless
    Questo errore è solitamente correlato a un problema dell'infrastruttura Google Cloud. Se il problema persiste, contatta l'assistenza Google Cloud.

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

Problemi comuni relativi alle autorizzazioni

  • Le API necessarie non sono abilitate nel progetto.

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

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

  • Il account di servizio mcsd o gkehub non dispone di autorizzazioni sufficienti

    Per una configurazione con un singolo progetto, tutte le autorizzazioni necessarie vengono concesse automaticamente ai service account creati automaticamente da GKE Hub e MCS.

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

Problemi noti

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 per tutti i servizi Kubernetes per un servizio 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 nel campo Servizio ports.targetPort e nel campo Deployment readinessProbe.httpGet.port anziché valori denominati.

NOTA: al momento, MCS ricava la porta del controllo di integrità per i servizi esportati solo dal readinessProbe del pod.

Un probe di idoneità non valido per un singolo servizio interrompe altri servizi

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

È importante mantenere l'integrità delle configurazioni per ogni servizio. Se un servizio MCS non viene aggiornato, assicurati che nessuno dei ServiceExport in nessuno dei cluster in nessuno dei namespace segnali ReadinessProbeError come motivo per cui la condizione di stato Exported è False. Consulta Esame di ServiceExports per scoprire come controllare le condizioni.

Passaggi successivi