Cette page explique comment examiner les problèmes de création, de mise à niveau et de redimensionnement de Anthos clusters on VMware (GKE On-Prem).
Comportement de journalisation par défaut pour gkectl
et gkeadm
Pour gkectl
et gkeadm
, l'utilisation des paramètres de journalisation par défaut est suffisante :
Pour
gkectl
, le fichier journal par défaut est/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
, et le fichier est lié symboliquement au fichierlogs/gkectl-$(date).log
dans le répertoire local où vous exécutezgkectl
.Pour
gkeadm
, le fichier journal par défaut estlogs/gkeadm-$(date).log
dans le répertoire local où vous exécutezgkeadm
.Le niveau de verbosité
-v5
par défaut couvre toutes les entrées de journal requises par l'équipe d'assistance.Le fichier journal contient la commande exécutée et le message d'échec.
Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.
Spécifier des emplacements autres que ceux par défaut pour les fichiers journaux
Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl
, utilisez l'option --log_file
. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.
Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm
, utilisez l'option --log_file
.
Localiser des journaux de l'API Cluster dans le cluster d'administrateur
Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez examiner le problème en inspectant les journaux du pod des contrôleurs d'API Cluster du cluster d'administrateur.
Recherchez le nom du pod des contrôleurs d'API Cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllers
Affichez les journaux de
vsphere-controller-manager
. Commencez par spécifier le pod, mais sans le conteneur :kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME
Le résultat vous indique que vous devez spécifier un conteneur et qu'il vous donne les noms des conteneurs du pod. Exemple :
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Choisissez un conteneur et affichez ses journaux:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Résoudre les problèmes liés à vSphere à l'aide de govc
Vous pouvez utiliser govc
pour examiner les problèmes liés à vSphere. Par exemple, vous pouvez confirmer les autorisations et l'accès de vos comptes utilisateur vCenter, et collecter les journaux vSphere.
Déboguer à l'aide des journaux du cluster d'amorçage
Lors de l'installation, Anthos clusters on VMware crée un cluster d'amorçage temporaire. Après une installation réussie, Anthos clusters on VMware supprime le cluster d'amorçage, vous laissant ainsi votre cluster d'administrateur et votre cluster d'utilisateur. En règle générale, vous ne devriez avoir aucune raison d'interagir avec le cluster d'amorçage.
Si vous transmettez --cleanup-external-cliuster=false
à gkectl create cluster
, le cluster d'amorçage n'est pas supprimé et vous pouvez utiliser les journaux du cluster d'amorçage pour déboguer les problèmes d'installation.
Recherchez les noms des pods en cours d'exécution dans l'espace de noms
kube-system
:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
Affichez les journaux d'un pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
Résoudre les problèmes F5 BIG-IP à l'aide du fichier kubeconfig interne
Après une installation, Anthos clusters on VMware génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug
dans le répertoire d'accueil du poste de travail administrateur. Ce fichier kubeconfig est identique au fichier kubeconfig de votre cluster d'administrateur, sauf qu'il pointe directement vers le nœud de plan de contrôle du cluster d'administrateur, où s'exécute le serveur d'API Kubernetes. Vous pouvez utiliser le fichier internal-cluster-kubeconfig-debug
pour résoudre les problèmes F5 BIG-IP.
Impossible de redimensionner un cluster d'utilisateur
Si un redimensionnement de cluster d'utilisateur échoue:
Recherchez les noms des MachineDeployments et des Machines:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Décrivez un MachineDeployment pour afficher ses journaux:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
Recherchez les erreurs sur les machines nouvellement créées:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Aucune adresse ne peut être allouée au redimensionnement du cluster
Ce problème se produit si le nombre d'adresses IP disponibles est insuffisant pour redimensionner un cluster d'utilisateur.
kubectl describe machine
affiche l'erreur suivante:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
Pour résoudre ce problème, allouez d'autres adresses IP pour le cluster. Supprimez ensuite la machine concernée :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME
Anthos Clusters on VMware crée une machine et l'attribue à l'une des nouvelles adresses IP disponibles.
Un nombre suffisant d'adresses IP est alloué, mais la machine ne parvient pas à s'enregistrer auprès du cluster
Ce problème peut survenir en cas de conflit d'adresses IP. Par exemple, une adresse IP que vous avez spécifiée pour une machine est utilisée pour un équilibreur de charge.
Pour résoudre ce problème, mettez à jour le fichier de bloc d'adresses IP du cluster afin que les adresses des machines n'entrent pas en conflit avec les adresses spécifiées dans votre fichier de configuration du cluster. ou votre fichier de blocs d'adresses IP Seesaw.
L'instantané est créé automatiquement en cas d'échec de création ou de mise à niveau du cluster d'administrateur.
Si vous tentez de créer ou de mettre à niveau un cluster d'administrateur et que l'opération échoue, Anthos clusters on VMware prend un instantané externe du cluster d'amorçage, qui est un cluster temporaire utilisé pour créer ou mettre à niveau le cluster d'administrateur. Bien que cet instantané du cluster d'amorçage soit semblable à l'instantané pris en exécutant la commande gkectl diagnose snapshot
sur le cluster d'administrateur, il présente l'avantage d'être déclenché automatiquement. Cet instantané du cluster d'amorçage contient des informations de débogage importantes pour le processus de création et de mise à niveau du cluster d'administrateur. Vous pouvez fournir cet instantané à l'assistance Google Cloud si nécessaire.
L'instantané externe inclut les journaux de pod de la ressource onprem-admin-cluster-controller
que vous pouvez afficher pour déboguer les problèmes de création ou de mise à niveau du cluster. Les journaux sont stockés dans un fichier distinct, par exemple:
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system
Les vérifications d'état sont exécutées automatiquement en cas d'échec de la mise à niveau du cluster.
Si vous tentez de mettre à niveau un cluster d'administrateur ou d'utilisateur et que cette opération échoue, Anthos clusters on VMware exécute automatiquement la commande gkectl diagnose cluster
sur le cluster.
Pour ignorer le diagnostic automatique, transmettez l'option --skip-diagnose-cluster
à gkectl upgrade
.
Le processus de mise à niveau est bloqué
En arrière-plan, Anthos clusters on VMware utilise la commande Kubernetes drain
lors d'une mise à niveau. Cette procédure drain
peut être bloquée par un déploiement si une seule instance dupliquée bénéficie d'un PodDisruptionBudget (PDB) créé avec minAvailable: 1
.
À partir de la version 1.13 de Clusters Anthos sur VMware, vous pouvez vérifier les échecs via les événements de pod Kubernetes.
Recherchez les noms des machines:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Recherchez les erreurs à l'aide de la commande
kubectl describe machine
:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Voici un exemple de résultat:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.
Pour une analyse plus détaillée de l'état des objets machine, exécutez gkectl diagnose cluster
:
... Checking machineset...SUCCESS Checking machine objects...FAILURE Reason: 1 machine objects error(s). Unhealthy Resources: Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB. ... Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3). ... Some validation results were FAILURE or UNKNOWN. Check report above.
Pour résoudre ce problème, enregistrez le budget d'interruption de pod et supprimez-le du cluster avant d'effectuer la mise à niveau. Vous pourrez ensuite rajouter le PDB une fois la mise à niveau terminée.
Diagnostiquer l'état de la machine virtuelle
Si un problème survient lors de la création de la machine virtuelle, exécutez gkectl diagnose cluster
pour obtenir un diagnostic de l'état de la machine virtuelle.
Voici un exemple de résultat :
- Validation Category: Cluster Healthiness Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking machine VMs...FAILURE Reason: 1 machine VMs error(s). Unhealthy Resources: Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e". Debug Information: null ... Exit with error: Cluster is unhealthy! Run gkectl diagnose cluster automatically in gkectl diagnose snapshot Public page https://cloud.google.com/anthos/clusters/docs/on-prem/1.13/diagnose#overview_diagnose_snapshot
Pour en savoir plus, consultez la page Diagnostiquer.
Recréer le fichier kubeconfig manquant du cluster d'utilisateur
Vous pouvez avoir besoin de recréer un fichier kubeconfig de cluster d'utilisateur dans plusieurs situations :
- Si vous tentez de créer un cluster d'utilisateur et que l'opération de création échoue mais que vous souhaitez obtenir le fichier kubeconfig de cluster d'utilisateur.
- Si le fichier kubeconfig de cluster d'utilisateur est manquant, par exemple après sa suppression.
Exécutez ces commandes pour recréer le fichier kubeconfig de cluster d'utilisateur :
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \ -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig
Remplacez les éléments suivants :
- USER_CLUSTER_VIP : adresse IP virtuelle principale de l'utilisateur.
- USER_CLUSTER_NAME : nom du cluster d'utilisateur.
- ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.