Cette page explique comment examiner les problèmes liés à la création, à la mise à niveau et au redimensionnement des clusters dans GKE sur VMware.
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).logdans le répertoire local où vous exécutezgkectl.Pour
gkeadm, le fichier journal par défaut estlogs/gkeadm-$(date).logdans le répertoire local où vous exécutezgkeadm.Le niveau de verbosité
-v5par 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-controllersAffichez 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_NAMELe 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
Le cluster de genre n'est pas supprimé
Lorsque vous créez un cluster d'administrateur, un cluster kind (également appelé cluster d'amorçage) est créé dans le cadre du processus. Une fois l'opération du cluster d'administrateur terminée, le cluster kind est automatiquement supprimé.
Si le message d'erreur Failed to delete the kind cluster s'affiche, vous pouvez effectuer les étapes suivantes sur votre poste de travail administrateur pour supprimer manuellement le cluster kind:
Obtenez l'ID du conteneur
kind:docker inspect --format="{{.Id}}" gkectl-control-planeObtenez l'ID de processus
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Arrêtez le processus:
sudo kill -9 PROCESS_ID
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, GKE sur VMware crée un cluster d'amorçage temporaire. Après une installation réussie, GKE sur VMware supprime le cluster d'amorçage, vous laissant 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-cluster=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
Pour obtenir les journaux directement à partir du cluster d'amorçage, vous pouvez exécuter la commande suivante lors de la création, de la mise à jour et de la mise à niveau du cluster:
docker exec -it gkectl-control-plane bash
La commande ouvre un terminal à l'intérieur du conteneur gkectl-control-plane qui s'exécute dans le cluster d'amorçage.
Pour inspecter les journaux kubelet et containerd, exécutez les commandes suivantes et recherchez les erreurs ou les avertissements dans le résultat:
systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
Effectuer le rollback d'un pool de nœuds après une mise à niveau
Si vous mettez à niveau un cluster d'utilisateur, puis constatez un problème avec les nœuds du cluster, vous pouvez effectuer un rollback des pools de nœuds sélectionnés vers la version précédente.
Le rollback des pools de nœuds sélectionnés est compatible avec les pools de nœuds Ubuntu et COS, mais pas pour les pools de nœuds Windows.
La version d'un pool de nœuds peut être identique à la version du plan de contrôle du cluster d'utilisateur ou une version mineure plus ancienne. Par exemple, si le plan de contrôle est la version 1.14, les pools de nœuds peuvent être la version 1.14 ou 1.13.
Afficher les versions de pool de nœuds disponibles
Supposons que vous ayez récemment mis à niveau les nœuds de calcul et le plan de contrôle de votre cluster d'utilisateur de la version 1.13.1-gke.35 vers la version 1.14.0, et que vous découvriez un problème avec les nœuds de calcul mis à niveau. Vous décidez donc d'effectuer un rollback d'un ou de plusieurs pools de nœuds vers la version que vous exécutiez précédemment : 1.13.1-gke.35.
Vérifiez que la version précédente est disponible pour le rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Effectuer un rollback des pools de nœuds
Vous pouvez effectuer le rollback d'un pool de nœuds à la fois ou de plusieurs pools de nœuds en une seule étape.
Dans le fichier de configuration de votre cluster d'utilisateur, dans un ou plusieurs pools de nœuds, définissez gkeOnPremVersion sur la version précédente (1.13.1-gke.35 dans cet exemple) :
nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...
Mettez à jour le cluster pour effectuer le rollback des pools de nœuds :
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Vérifiez que le rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
pool-1 a été restauré vers la version 1.13.1-gke.35.
user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Effectuer la mise à niveau vers une nouvelle version du correctif
Supposons que le problème soit résolu dans une nouvelle version du correctif, par exemple 1.14.1. Vous pouvez maintenant mettre à niveau tous les pools de nœuds et le plan de contrôle vers la nouvelle version du correctif.
Dans le fichier de configuration de votre cluster d'utilisateur:
Définissez la valeur de
gkeOnPremVersionsur la nouvelle version du correctif (1.14.1-gke.x) dans cet exemple.Pour chaque pool de nœuds, supprimez le champ
gkeOnPremVersionou définissez-le sur la chaîne vide. Si aucune version n'est spécifiée pour un pool de nœuds, la version du pool de nœuds est définie par défaut sur la version spécifiée pour le cluster.
Exemple :
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
Exécutez gkectl prepare et gkectl upgrade cluster comme décrit dans la section Mettre à niveau GKE sur VMware.
Vérifiez la nouvelle version du cluster et affichez les versions désormais disponibles pour le rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y
Résoudre les problèmes F5 BIG-IP à l'aide du fichier kubeconfig interne
Après une installation, GKE sur VMware génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug dans le répertoire d'accueil de votre 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_NAMERecherchez 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_NAMEGKE sur VMware crée une machine et lui 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 cette opération échoue, GKE sur 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, GKE sur 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é
GKE sur VMware, en arrière-plan, 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 GKE 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/latest/diagnose#overview_diagnose_snapshot
Pour en savoir plus, consultez Diagnostiquer les problèmes de cluster.
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 la commande suivante pour recréer le fichier kubeconfig du cluster d'utilisateur:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
Remplacez les éléments suivants :
- USER_CLUSTER_KUBECONFIG: nom du nouveau fichier kubeconfig pour votre cluster d'utilisateur.
- ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig pour votre cluster d'administrateur.
Supprimez les modifications non compatibles pour débloquer la mise à niveau
Lorsque vous mettez à niveau des clusters vers la version 1.16 ou une version antérieure, les modifications apportées à la plupart des champs sont ignorées en mode silencieux pendant la mise à niveau. Cela signifie que ces modifications ne prennent pas effet pendant et après la mise à niveau.
Lors de la mise à niveau des clusters d'utilisateur vers la version 1.28 ou une version ultérieure, nous validons toutes les modifications apportées dans le fichier de configuration et renvoyons une erreur pour les modifications non compatibles, au lieu de simplement les ignorer. Par exemple, si vous tentez de désactiver la réparation automatique de nœuds lors de la mise à niveau d'un cluster d'utilisateur vers la version 1.28, la mise à niveau échouera et affichera le message d'erreur suivant:
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
Pour contourner cette erreur, plusieurs solutions s'offrent à vous:
- Annulez la modification tentée, puis relancez la mise à niveau. Par exemple, dans le scénario précédent, vous annulez les modifications apportées à la configuration
AutoRepair, puis réexécutezgkectl upgrade. - Vous pouvez également générer des fichiers de configuration correspondant à l'état actuel du cluster en exécutant
gkectl get-config, mettre à jour les champsgkeOnPremVersiondu cluster et des pools de nœuds dans le fichier de configuration, puis réexécutergkectl upgrade.
Erreurs de commande gkectl lors de l'utilisation de VPC Service Controls
Si vous utilisez VPC Service Controls, des erreurs peuvent se produire lorsque vous exécutez certaines commandes gkectl, telles que "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services". Pour éviter ces erreurs, ajoutez le paramètre --skip-validation-gcp à vos commandes.