Résoudre les problèmes liés à Distributed Cloud connecté

Google surveille et gère à distance le matériel Google Distributed Cloud Connected. Pour ce faire, les ingénieurs Google disposent d'un accès Secure Shell (SSH) au matériel Distributed Cloud connecté. Si Google détecte un problème, un ingénieur Google vous contacte pour le résoudre. Si vous avez identifié un problème vous-même, contactez immédiatement l'assistance Google pour le diagnostiquer et le résoudre.

Perte de connectivité réseau

Si le matériel Distributed Cloud connecté perd sa connexion àGoogle Cloud et reste déconnecté pendant 120 secondes, le plan de contrôle Distributed Cloud connecté marque les pods concernés comme "Not Ready" (Non prêt) et lance l'éviction des pods.

Pour atténuer ce risque, vous devez planifier votre configuration Distributed Cloud connectée et concevoir vos charges de travail pour le niveau de disponibilité de votre choix. Pour en savoir plus, consultez les bonnes pratiques concernant la disponibilité.

Sessions BGP corrompues dans les ressources Cloud Router utilisées par les connexions VPN

Les connexions Distributed Cloud VPN s'appuient sur des sessions BGP établies et gérées par leurs ressources Cloud Router correspondantes pour annoncer les routes entre le cluster Distributed Cloud connecté et Google Cloud. Si vous modifiez la configuration d'une ressource Cloud Router associée à une connexion VPN Distributed Cloud, cette connexion peut cesser de fonctionner.

Pour récupérer la configuration de session BGP corrompue dans le routeur Cloud Router concerné, procédez comme suit :

  1. Dans la console Google Cloud , obtenez le nom de la session BGP corrompue. Exemple :

    INTERFACE=anthos-mcc-34987234

  2. Obtenez les adresses IP BGP du pair et du routeur cloud pour la session BGP corrompue, ainsi que le numéro ASN du pair utilisé par la connexion Distributed Cloud VPN concernée. Exemple :

    GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506

    Si vous avez supprimé la session BGP, obtenez ces informations à partir du cluster connecté Distributed Cloud :

    1. Obtenez les identifiants du cluster :

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

      Remplacez les éléments suivants :

      • CLUSTER_ID : nom du cluster cible.
      • REGION : région Google Cloud dans laquelle le cluster cible est créé.
      • PROJECT_ID : ID du projet Google Cloud cible.

    2. Obtenez la configuration de la ressource MultiClusterConnectivityConfig :

      kubectl get multiclusterconnectivityconfig -A

      La commande renvoie un résultat semblable à celui-ci :

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

    3. Obtenez l'adresse IP BGP du pair, l'adresse IP du routeur cloud et le numéro ASN de la session BGP :

      kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME

      Remplacez MCC_CONFIG_NAME par le nom de l'MultiClusterConfigResource que vous avez obtenu à l'étape précédente.

      La commande renvoie un résultat semblable à celui-ci :

       ​​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. Dans la console Google Cloud , obtenez le nom, la région et le nom du projetGoogle Cloud du tunnel VPN corrompu. Exemple :

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

  4. Supprimez la session BGP corrompue de la configuration du routeur Cloud Router.

  5. Créez une interface Cloud Router :

    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

    Remplacez les éléments suivants :

    • INTERFACE_NAME : nom descriptif qui identifie de manière unique cette interface.
    • TUNNEL_NAME : nom du tunnel VPN que vous avez obtenu à l'étape précédente.
    • ROUTER_BGP_IP : adresse IP BGP du routeur Cloud Router que vous avez obtenue précédemment dans cette procédure.
    • VPC_PROJECT_ID : ID du projetGoogle Cloud VPC cible.
    • REGION : Google Cloud région dans laquelle le projet Google Cloud VPC cible a été créé.

  6. Créez le pair 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

    Remplacez les éléments suivants :

    • INTERFACE_NAME : nom de l'interface que vous avez créée à l'étape précédente.
    • TUNNEL_NAME : nom du tunnel VPN que vous avez utilisé pour créer l'interface à l'étape précédente.
    • REGION : région Google Cloud dans laquelle le projet Google Cloud VPC cible est créé.
    • VPC_PROJECT_ID : ID du projetGoogle Cloud VPC cible.
    • GDCE_BGP_IP : adresse IP BGP du pair Distributed Cloud que vous avez obtenue précédemment dans cette procédure.
    • GDCE_BGP_ASN : numéro ASN BGP du pair Distributed Cloud que vous avez obtenu précédemment dans cette procédure.

À ce stade, la session BGP est de nouveau opérationnelle.

Nœud bloqué à l'état Ready,SchedulingDisabled

Lorsque vous appliquez ou supprimez la ressource NodeSystemConfigUpdate ou SriovNetworkNodePolicy, le nœud cible peut redémarrer. Lorsqu'un nœud redémarre, son état passe à NotReady ou Scheduling Disabled. Si un nœud reste à l'état Ready,SchedulingDisabled pendant plus de 30 minutes, procédez comme suit :

  1. Vérifiez la configuration et l'état de la ressource NodeSystemConfigUpdate ou SriovNetworkNodePolicy correspondante. Si la ressource SriovNetworkNodePolicy n'existe pas, le nœud n'est pas compatible avec SR-IOV.

  2. Si l'état de la ressource est Succeeded, activez la planification sur le nœud à l'aide de la commande suivante :

    kubectl uncordon NODE_NAME.

    Remplacez NODE_NAME par le nom du nœud cible.

  3. Si le problème persiste, contactez l'assistance Google.