Résoudre les problèmes de création ou de mise à niveau des clusters

Cette page vous explique comment résoudre les problèmes liés à l'installation ou à la mise à niveau des clusters Google Distributed Cloud.

Problèmes d'installation

Les sections suivantes peuvent vous aider à résoudre les problèmes d'installation de Google Distributed Cloud.

Messages d'erreur temporaires

Le processus d'installation de Google Distributed Cloud est une boucle de rapprochement continu. Par conséquent, des messages d'erreur temporaires peuvent apparaître dans le journal pendant l'installation.

Tant que l'installation se termine bien, vous pouvez ignorer ces erreurs. Voici la liste des messages d'erreurs temporaires du journal :

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

Si la clé de votre compte de service Google Cloud a expiré, bmctl affiche les messages d'erreur suivants :

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

Vous devez générer une nouvelle clé de compte de service.

Utiliser le cluster d'amorçage pour déboguer les problèmes

Lorsque Google Distributed Cloud crée des clusters autogérés (administrateur, hybrides ou autonomes), il déploie un cluster Kubernetes in Docker (kind) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la création des clusters. Ce cluster temporaire est appelé cluster d'amorçage. Les clusters d'utilisateur sont créés et mis à niveau par leur cluster d'administrateur ou hybride de gestion sans utiliser de cluster d'amorçage.

Si un cluster kind existe déjà dans votre déploiement lorsque vous tentez l'installation, Google Distributed Cloud supprime le cluster kind existant. La suppression ne se produit qu'après la réussite de l'installation ou de la mise à niveau. Pour conserver le cluster kind existant même après la réussite de l'opération, utilisez l'option --keep-bootstrap-cluster de bmctl.

Google Distributed Cloud crée un fichier de configuration pour le cluster d'amorçage sous WORKSPACE_DIR/.kindkubeconfig. Vous ne pouvez vous connecter au cluster d'amorçage que lors de la création et de la mise à niveau du cluster.

Le cluster d'amorçage doit accéder à un dépôt Docker pour extraire des images. Par défaut, le registre est défini sur Artifact Registry, sauf si vous utilisez un registre privé. Lors de la création du cluster, bmctl crée les fichiers suivants :

  • bmctl-workspace/config.json : contient les identifiants du compte de service Google Cloud pour l'accès au registre. Les identifiants sont obtenus à partir du champ gcrKeyPath du fichier de configuration du cluster.

  • bmctl-workspace/config.toml : contient la configuration containerd dans le cluster de genre.

Examiner les journaux du cluster d'amorçage

Pour déboguer le cluster d'amorçage, procédez comme suit :

  • Connectez-vous au cluster d'amorçage lors de sa création et de sa mise à niveau.
  • Récupérez les journaux du cluster d'amorçage.

Vous pouvez trouver les journaux de la machine que vous utilisez pour exécuter bmctl dans les dossiers suivants :

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Remplacez CLUSTER_NAME et TIMESTAMP par le nom de votre cluster et l'heure du système correspondant.

Pour obtenir les journaux directement à partir du cluster d'amorçage, vous pouvez exécuter la commande suivante lors de la création et de la mise à niveau du cluster :

docker exec -it bmctl-control-plane bash

La commande ouvre un terminal dans le conteneur de plan de contrôle bmctl qui s'exécute dans le cluster d'amorçage.

Pour inspecter les journaux kubelet et containerd, utilisez les commandes suivantes et recherchez toute erreur ou tout avertissement dans le résultat :

journalctl -u kubelet
journalctl -u containerd

Activer la journalisation de débogage containerd

Si les journaux containerd standards ne fournissent pas suffisamment d'informations pour résoudre les problèmes, vous pouvez augmenter le niveau de journalisation. Il est souvent nécessaire d'augmenter le niveau de journalisation pour diagnostiquer des problèmes complexes, tels que des problèmes liés à un miroir de registre ou des erreurs ImagePullBackOff.

Pour augmenter le niveau de journalisation, procédez comme suit :

  1. Activez la journalisation du débogage :

    1. Ouvrez le fichier de configuration containerd (/etc/containerd/config.toml) à l'aide de l'éditeur de texte de votre choix.

    2. Dans le fichier, recherchez la section [debug] et remplacez la valeur de level ("") par "debug".

    3. Enregistrez le fichier et quittez l'éditeur de texte.

    4. Vérifiez que vous avez bien mis à jour le fichier de configuration :

      cat /etc/containerd/config.toml | grep debug

      La sortie doit ressembler à l'exemple suivant :

      [debug]
  level = "debug"
    shim_debug = false

    5. Pour appliquer la modification du niveau de journalisation, redémarrez containerd :

      sudo systemctl restart containerd

  2. Pour générer de nouvelles entrées de journal, essayez d'extraire une image qui n'existe pas ou qui n'est utilisée par aucun nœud ni cluster. Exemple :

    # This command fails because the image doesn't exist
crictl pull us-west1-docker.pkg.dev/gdc-project/samples/non-existent-image:latest

    Cela oblige containerd à effectuer une action et à générer des journaux détaillés.

  3. Attendez que l'image soit extraite ou que l'opération échoue, puis collectez les journaux containerd dans un fichier nommé containerd_log.txt :

    journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt

    Remplacez TIME_PERIOD par une valeur spécifiant l'heure de début des journaux. Placez entre guillemets doubles toute valeur contenant des espaces. Exemple :"2 hours ago"

  4. Une fois le dépannage terminé, rétablissez le niveau de journalisation par défaut. Si vous laissez la journalisation du débogage activée, vos journaux système peuvent être saturés, les performances peuvent être affectées et des informations sensibles peuvent être exposées.

    1. Ouvrez le fichier /etc/containerd/config.toml et remplacez la valeur de level par "", le niveau de journalisation par défaut.

    2. Vérifiez que vous avez bien mis à jour la configuration :

      cat /etc/containerd/config.toml | grep level

      La sortie doit ressembler à l'exemple suivant :

      level = ""

    3. Pour appliquer la modification, redémarrez containerd :

      sudo systemctl restart containerd

      Votre système est maintenant revenu à sa configuration de journalisation standard.

Problèmes de mise à niveau du cluster

Lorsque vous mettez à niveau des clusters Google Distributed Cloud, vous pouvez surveiller la progression et vérifier l'état de vos clusters et de vos nœuds.

Les conseils suivants peuvent vous aider à déterminer si la mise à niveau se déroule normalement ou s'il y a un problème.

Surveiller la progression de la mise à niveau

Utilisez la commande kubectl describe cluster pour afficher l'état d'un cluster pendant le processus de mise à niveau :

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAME : nom du cluster
  • CLUSTER_NAMESPACE : espace de noms de votre cluster.
  • ADMIN_KUBECONFIG : fichier kubeconfig de l'administrateur.
    • Par défaut, les clusters d'administrateur, hybrides et autonomes utilisent une mise à niveau sur place. Si vous utilisez l'option --use-bootstrap=true avec la commande bmctl upgrade, l'opération de mise à niveau utilise un cluster d'amorçage. Pour surveiller la progression de la mise à niveau lorsqu'un cluster de démarrage est utilisé, spécifiez le chemin d'accès au fichier kubeconfig du cluster d'amorçage, .kindkubeconfig. Ce fichier se trouve dans le répertoire de l'espace de travail.

Consultez la section Status de la sortie, qui affiche un récapitulatif de l'état de la mise à niveau du cluster. Si le cluster signale une erreur, utilisez les sections suivantes pour identifier le problème.

Vérifier si les nœuds sont prêts

Utilisez la commande kubectl get nodes pour afficher l'état des nœuds d'un cluster pendant le processus de mise à niveau :

kubectl get nodes --kubeconfig KUBECONFIG

Pour vérifier si un nœud a bien terminé le processus de mise à niveau, examinez les colonnes VERSION et AGE dans la réponse de la commande. VERSION correspond à la version de Kubernetes pour le cluster. Pour connaître la version de Kubernetes pour une version donnée de Google Distributed Cloud, consultez Gestion des versions.

Si le nœud affiche NOT READY, essayez de le connecter et vérifiez l'état de kubelet :

systemctl status kubelet

Vous pouvez également examiner les journaux kubelet :

journalctl -u kubelet

Examinez la sortie de l'état et des journaux kubelet pour identifier les messages indiquant pourquoi le nœud présente un problème.

Vérifier quel nœud est en cours de mise à niveau

Pour vérifier quel nœud du cluster est en cours de mise à niveau, utilisez la commande kubectl get baremetalmachines :

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAMESPACE : espace de noms de votre cluster.
  • ADMIN_KUBECONFIG : fichier kubeconfig de l'administrateur.
    • Si un cluster d'amorçage est utilisé pour une mise à niveau d'un cluster d'administrateur, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (bmctl-workspace/.kindkubeconfig).

L'exemple de résultat suivant montre que le nœud en cours de mise à niveau a un ABM VERSION différent de DESIRED ABM VERSION :

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Vérifier quels nœuds sont en cours de drainage

Lors de la mise à niveau, les nœuds sont vidés de leurs pods et la planification est désactivée jusqu'à ce que le nœud soit correctement mis à niveau. Pour voir quels nœuds sont en train d'être supprimés, utilisez la commande kubectl get nodes :

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

La colonne STATUS est filtrée à l'aide de grep pour n'afficher que les nœuds qui signalent SchedulingDisabled. Cet état indique que les nœuds sont en cours de drainage.

Vous pouvez également vérifier l'état du nœud à partir du cluster d'administrateur :

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAMESPACE : espace de noms de votre cluster.
  • ADMIN_KUBECONFIG : fichier kubeconfig de l'administrateur.
    • Si un cluster d'amorçage est utilisé pour une mise à niveau d'un cluster d'administrateur, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (bmctl-workspace/.kindkubeconfig).

Le nœud en cours de drainage affiche l'état dans la colonne MAINTENANCE.

Vérifier pourquoi un nœud est à l'état "Drainage" depuis longtemps

Utilisez l'une des méthodes de la section précédente pour identifier le nœud en cours de drainage à l'aide de la commande kubectl get nodes. Utilisez la commande kubectl get pods et filtrez sur le nom de ce nœud pour afficher des informations supplémentaires :

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Remplacez NODE_NAME par le nom du nœud en cours de drainage. Le résultat renvoie une liste des pods bloqués ou lents à vider. La mise à niveau se poursuit, même avec des pods bloqués, lorsque le processus de drainage sur un nœud prend plus de 20 minutes.

À partir de la version 1.29, le processus de drainage des nœuds utilise l'API Eviction, qui respecte les PodDisruptionBudgets (PDB).

Les paramètres PDB suivants peuvent entraîner des problèmes de drainage de nœud :

  • Pods gérés par plusieurs PDB

  • Configurations statiques PDB telles que les suivantes :

    • maxUnavailable == 0
    • minUnavailable >= nombre total d'instances répliquées

    Le nombre total d'instances répliquées est difficile à déterminer à partir de la ressource PDB, car il est défini dans une ressource de niveau supérieur, telle que Deployment, ReplicaSet ou StatefulSet. Les PDB correspondent aux pods en fonction du sélecteur de leur configuration uniquement. Pour déterminer si une configuration PDB statique est à l'origine d'un problème, il est recommandé de vérifier si pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy en premier lieu et de voir si l'une des configurations statiques mentionnées permet que cela se produise.

Les cas de non-respect de l'environnement d'exécution, tels que la valeur DisruptionsAllowed calculée pour une ressource PDB égale à 0, peuvent également bloquer le drainage des nœuds. Si des objets PodDisruptionBudget sont configurés pour ne pas autoriser d'autres interruptions, les mises à niveau de nœuds peuvent échouer à passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'effectuer un scaling à la hausse de Deployment ou HorizontalPodAutoscaler afin de permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget.

Pour afficher tous les objets PodDisruptionBudget qui n'autorisent aucune interruption, utilisez la commande suivante :

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Vérifier pourquoi les pods ne sont pas opérationnels

Les mises à niveau peuvent échouer si un pod contient des adresses IP de plan de contrôle upgrade-first-node ou upgrade-node. Ce comportement est généralement dû au fait que les pods statiques ne sont pas opérationnels.

  1. Vérifiez les pods statiques à l'aide de la commande crictl ps -a et recherchez les pods Kubernetes ou etcd en cas de plantage. Si des pods ont échoué, consultez leurs journaux pour comprendre pourquoi ils plantent.

    Voici quelques exemples de comportements de boucle de plantage :

    • Les autorisations ou le propriétaire des fichiers montés sur des pods statiques ne sont pas corrects.
    • La connectivité à l'adresse IP virtuelle ne fonctionne pas.
    • Problèmes liés à etcd.

  2. Si la commande crictl ps ne fonctionne pas ou ne renvoie rien, vérifiez l'état de kubelet et de containerd. Utilisez les commandes systemctl status SERVICE et journalctl -u SERVICE pour consulter les journaux.

Étape suivante

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes :

  • Conditions requises pour ouvrir une demande d'assistance.
  • Des outils pour vous aider à résoudre les problèmes, comme la configuration de votre environnement, les journaux et les métriques.
  • Composants acceptés.