Risolvi i problemi di Distributed Cloud connesso

Google monitora e gestisce da remoto l'hardware di Google Distributed Cloud connected. A questo scopo, gli ingegneri Google hanno accesso Secure Shell (SSH) all'hardware Distributed Cloud connesso. Se Google rileva un problema, un tecnico di Google ti contatta per risolverlo. Se hai identificato un problema, contatta immediatamente l'Assistenza Google per diagnosticarlo e risolverlo.

Perdita di connettività di rete

Se l'hardware di Distributed Cloud connesso perde la connessione a Google Cloud e rimane disconnesso per 120 secondi, il control plane di Distributed Cloud connesso contrassegna i pod interessati come "Not Ready" e avvia l'espulsione dei pod.

Per risolvere questo problema, devi pianificare la configurazione di Distributed Cloud Connected e progettare i tuoi workload per il livello di disponibilità scelto. Per saperne di più, consulta le best practice per la disponibilità.

Sessioni BGP danneggiate nelle risorse del router Cloud utilizzate dalle connessioni VPN

Le connessioni Distributed Cloud VPN si basano su sessioni BGP stabilite e gestite dalle risorse router Cloud corrispondenti per annunciare le route tra il cluster connesso a Distributed Cloud e Google Cloud. Se modifichi la configurazione di una risorsa router Cloud associata a una connessione VPN Distributed Cloud, questa connessione potrebbe smettere di funzionare.

Per recuperare la configurazione della sessione BGP danneggiata nel router Cloud interessato, completa i seguenti passaggi:

  1. Nella console Google Cloud , recupera il nome della sessione BGP danneggiata. Ad esempio:

    INTERFACE=anthos-mcc-34987234

  2. Recupera gli indirizzi IP BGP peer e BGP del router Cloud per la sessione BGP danneggiata, nonché l'ASN peer utilizzato dalla connessione Distributed Cloud VPN interessata. Ad esempio:

    GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506

    Se hai eliminato la sessione BGP, recupera queste informazioni dal cluster Distributed Cloud connesso:

    1. Recupera le credenziali del cluster:

      gcloud edge-cloud container clusters get-credentials CLUSTER_ID \
  --location REGION \
  --project PROJECT_ID

      Sostituisci quanto segue:

      • CLUSTER_ID: il nome del cluster di destinazione.
      • REGION: la regione Google Cloud in cui viene creato il cluster di destinazione.
      • PROJECT_ID: l'ID del progetto Google Cloud di destinazione.

    2. Ottieni la configurazione della risorsa MultiClusterConnectivityConfig:

      kubectl get multiclusterconnectivityconfig -A

      Il comando restituisce un output simile al seguente:

       NAMESPACE     NAME                   LOCAL ASN              PEER ASN
 kube-system   MultiClusterConfig1    65505                   65506
 ```

    3. Recupera l'indirizzo IP BGP peer, l'indirizzo IP del router Cloud e l'ASN della sessione BGP:

      kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME

      Sostituisci MCC_CONFIG_NAME con il nome di MultiClusterConfigResource che hai ottenuto nel passaggio precedente.

      Il comando restituisce un output simile al seguente:

       ​​Spec:
 Asns:
   Peer:  65505
   Self:  65506 # GDCE ASN
 Tunnels:
   Ike Key:
     Name:       MCC_CONFIG_NAME-0
     Namespace:  kube-system
   Peer:
     Bgp IP:      169.254.208.73 # Cloud Router BGP IP
     Private IP:  34.157.98.148
     Public IP:   34.157.98.148
   Self:
     Bgp IP:      169.254.208.74 # GDCE BGP IP
     Private IP:  10.100.29.49
     Public IP:   208.117.254.68
 ```

  3. Nella console Google Cloud , recupera il nome, la regione e il nome del progettoGoogle Cloud per il tunnel VPN danneggiato. Ad esempio:

    VPN_TUNNEL=VPNTunnel1
REGION=US-East1
VPC_PROJECT_ID=VPC-Project-1

  4. Elimina la sessione BGP danneggiata dalla configurazione del router Cloud.

  5. Crea una nuova interfaccia del router Cloud:

    gcloud compute routers add-interface --interface-name=INTERFACE_NAME \
   --vpn-tunnel=TUNNEL_NAME \ 
   --ip-address=ROUTER_BGP_IP \
   --project=VPC_PROJECT_ID \
   --region=REGION \      
   --mask-length=30

    Sostituisci quanto segue:

    • INTERFACE_NAME: un nome descrittivo che identifica in modo univoco questa interfaccia.
    • TUNNEL_NAME: il nome del tunnel VPN ottenuto nel passaggio precedente.
    • ROUTER_BGP_IP: l'indirizzo IP BGP del router Cloud che hai ottenuto in precedenza in questa procedura.
    • VPC_PROJECT_ID: l'ID del progettoGoogle Cloud VPC di destinazione.
    • REGION: la regione Google Cloud in cui è stato creato il progetto VPC di destinazione Google Cloud .

  6. Crea il peer BGP:

    gcloud compute routers add-bgp-peer --interface=INTERFACE_NAME \
   --peer-name=TUNNEL_NAME \
   --region REGION \
   --project=VPC_PROJECT_ID \
   --peer-ip-address=GDCE_BGP_IP \
   --peer-asn=GDCE_BGP_ASN \
   --advertised-route-priority=100 \
   --advertisement-mode=DEFAULT

    Sostituisci quanto segue:

    • INTERFACE_NAME: il nome dell'interfaccia creata nel passaggio precedente.
    • TUNNEL_NAME: il nome del tunnel VPN che hai utilizzato per creare l'interfaccia nel passaggio precedente.
    • REGION: la regione Google Cloud in cui viene creato il progetto VPC di destinazione Google Cloud .
    • VPC_PROJECT_ID: l'ID del progettoGoogle Cloud VPC di destinazione.
    • GDCE_BGP_IP: l'indirizzo IP BGP peer di Distributed Cloud che hai ottenuto in precedenza in questa procedura.
    • GDCE_BGP_ASN: l'ASN BGP peer di Distributed Cloud che hai ottenuto in precedenza in questa procedura.

A questo punto, la sessione BGP è di nuovo attiva e operativa.

Il nodo è bloccato nello stato Ready,SchedulingDisabled

Quando applichi o elimini la risorsa NodeSystemConfigUpdate o SriovNetworkNodePolicy, il nodo di destinazione potrebbe riavviarsi. Quando un nodo viene riavviato, il suo stato cambia in NotReady o Scheduling Disabled. Se un nodo rimane nello stato Ready,SchedulingDisabled per più di 30 minuti, procedi nel seguente modo:

  1. Controlla la configurazione e lo stato della risorsa NodeSystemConfigUpdate o SriovNetworkNodePolicy corrispondente. Se la risorsa SriovNetworkNodePolicy non esiste, il nodo non è in grado di supportare SR-IOV.

  2. Se lo stato della risorsa è Succeeded, attiva la pianificazione sul nodo utilizzando il seguente comando:

    kubectl uncordon NODE_NAME.

    Sostituisci NODE_NAME con il nome del nodo di destinazione.

  3. Se il problema persiste, contatta l'Assistenza Google.