Cette page explique comment résoudre les problèmes liés à l'installation ou à la mise à niveau des clusters Google Distributed Cloud.
Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.Problèmes d'installation
Les sections suivantes peuvent vous aider à résoudre les problèmes liés à l'installation de Google Distributed Cloud.
Messages d'erreur temporaires
Le processus d'installation de Google Distributed Cloud est une boucle de rapprochement continue. 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 dans Docker (kind) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la création de clusters. Ce cluster temporaire est appelé cluster d'amorçage. Les clusters d'utilisateur sont créés et mis à niveau par leur administrateur ou cluster hybride, sans utiliser de cluster d'amorçage.
Si un cluster de genre existe déjà dans votre déploiement lors de la tentative d'installation, Google Distributed Cloud le supprime. La suppression ne se produit qu'après la réussite de l'installation ou de la mise à niveau.
Pour conserver le cluster de genre existant même après une opération réussie, 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 Container 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 champgcrKeyPath
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
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.
- Si vous rencontrez des problèmes lors d'une mise à niveau, essayez de déterminer à quelle étape l'échec se produit. Pour en savoir plus sur ce qu'il advient d'un cluster pendant le processus de mise à niveau, consultez la section Cycle de vie et étapes des mises à niveau du cluster.
- Pour en savoir plus sur l'impact d'un problème lors de la mise à niveau d'un cluster, consultez la page Comprendre l'impact des défaillances dans Google Distributed Cloud.
Les conseils suivants peuvent vous aider à déterminer si la mise à niveau se poursuit normalement ou s'il y a un problème.
Suivre 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 de votre cluster.CLUSTER_NAMESPACE
: espace de noms de votre cluster.ADMIN_KUBECONFIG
: fichier d'administration kubeconfig.- 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 commandebmctl upgrade
, l'opération de mise à niveau utilise un cluster d'amorçage. Pour surveiller la progression de la mise à niveau lorsqu'un cluster d'amorçage 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.
- Par défaut, les clusters d'administrateur, hybrides et autonomes utilisent une mise à niveau sur place.
Si vous utilisez l'option
Examinez la section Status
du résultat, qui affiche l'état agrégé de la mise à niveau du cluster. Si le cluster signale une erreur, reportez-vous aux sections suivantes pour déterminer l'origine du problème.
Vérifier si les nœuds sont prêts
Exécutez 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 terminé le processus de mise à niveau, consultez les colonnes VERSION
et AGE
dans la réponse de la commande. VERSION
correspond à la version Kubernetes du cluster. Pour connaître la version de Kubernetes associée à une version Google Distributed Cloud donnée, consultez la section Historique des versions.
Si le nœud affiche NOT READY
, essayez de le connecter et de vérifier l'état du kubelet:
systemctl status kubelet
Vous pouvez également consulter les journaux du kubelet:
journalctl -u kubelet
Examinez la sortie de l'état du kubelet et les journaux des messages indiquant la raison pour laquelle le nœud rencontre un problème.
Vérifier le nœud 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 d'administration kubeconfig.- Si un cluster d'amorçage est utilisé pour une mise à niveau d'administration, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (
bmctl-workspace/.kindkubeconfig
).
- Si un cluster d'amorçage est utilisé pour une mise à niveau d'administration, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (
L'exemple de résultat suivant montre que le nœud en cours de mise à niveau possède 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
Identifier les nœuds en cours de drainage
Au cours du processus de mise à niveau, les nœuds sont drainés de pods et la planification est désactivée jusqu'à ce que le nœud soit mis à niveau avec succès. Pour identifier les nœuds en cours de drainage, exécutez 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 la valeur grep
pour n'afficher que les nœuds indiquant 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 d'administration kubeconfig.- Si un cluster d'amorçage est utilisé pour une mise à niveau d'administration, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (
bmctl-workspace/.kindkubeconfig
).
- Si un cluster d'amorçage est utilisé pour une mise à niveau d'administration, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (
Le nœud en cours de drainage affiche son état dans la colonne MAINTENANCE
.
Vérifier pourquoi un nœud est à l'état de drainage depuis longtemps
Utilisez l'une des méthodes de la section précédente pour identifier le nœud à drainer à l'aide de la commande kubectl get nodes
. Utilisez la commande kubectl get
pods
et filtrez ce nom de 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 la liste des pods bloqués ou lents à drainer. 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 des nœuds:
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
ouStatefulSet
. Les PDB ne sont mis en correspondance qu'avec les pods en fonction du sélecteur de leur configuration. Une bonne approche pour diagnostiquer si une configuration PDB statique est à l'origine du problème consiste à commencer par déterminer sipdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
et à voir si l'une des configurations statiques mentionnées permet ce problème.
Les violations d'exécution, telles que la valeur DisruptionsAllowed
calculée pour une ressource PDB 0
, peuvent également bloquer le drainage des nœuds. Si vous avez configuré des objets PodDisruptionBudget
qui ne peuvent pas autoriser d'autres interruptions, les mises à niveau de nœuds risquent de ne pas parvenir à 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 de HorizontalPodAutoscaler
pour permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget
.
Pour afficher tous les objets PodDisruptionBudget
qui n'autorisent pas d'interruptions, 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.
Vérifiez les pods statiques à l'aide de la commande
crictl ps -a
et recherchez les pods Kubernetes ouetcd
qui plantent. Si des pods sont défaillants, consultez leurs journaux pour savoir pourquoi ils plantent.Voici quelques exemples de comportement en boucle de plantage:
- Les autorisations ou le propriétaire des fichiers installés sur des pods statiques ne sont pas corrects.
- La connectivité à l'adresse IP virtuelle ne fonctionne pas.
- Problèmes liés à
etcd
.
Si la commande
crictl ps
ne fonctionne pas ou ne renvoie rien, vérifiez les étatskubelet
etcontainerd
. Utilisez les commandessystemctl status SERVICE
etjournalctl -u SERVICE
pour consulter les journaux.
Étapes suivantes
- Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.