Dans Google Distributed Cloud, la vérification périodique de l'état et la réparation automatique des nœuds sont activées par défaut.
La fonctionnalité de réparation automatique des nœuds détecte et répare en continu les nœuds non opérationnels d'un cluster.
Des vérifications d'état périodiques sont effectuées toutes les quinze minutes. Les vérifications sont identiques à celles effectuées par gkectl diagnose cluster
. Les résultats apparaissent dans les journaux et événements liés aux objets Cluster dans le cluster d'administrateur.
Assurez-vous que vos clusters d'administrateur et d'utilisateur disposent chacun d'une adresse IP supplémentaire disponible pour la réparation automatique des nœuds.
Si le cluster avancé est activé, les vérifications d'état périodiques ne sont pas exécutées dans le cadre de la réparation automatique.
Conditions de nœud non opérationnelles lorsque le cluster avancé n'est pas activé
Les conditions suivantes indiquent qu'un nœud n'est pas opérationnel lorsque enableAdvanceCluster
est false
.
La condition de nœud
NotReady
a la valeurtrue
pendant environ 10 minutes.L'état de la machine est
Unavailable
pendant environ 10 minutes après sa création.L'état de la machine n'est pas
Available
pendant environ 30 minutes après la création de la VM.Aucun objet Nœud (nodeRef est
nil
) ne correspondant à une machine à l'étatAvailable
pendant environ 10 minutes.La condition de nœud
DiskPressure
a la valeurtrue
pendant environ 30 minutes.
Conditions de nœud non opérationnelles lorsque le cluster avancé est activé
Les conditions suivantes indiquent qu'un nœud n'est pas opérationnel lorsque enableAdvanceCluster
est true
.
La condition de nœud
NotReady
a la valeurtrue
pendant environ 10 minutes.La condition de nœud
DiskPressure
a la valeurtrue
pendant environ 30 minutes.
Stratégie de réparation des nœuds
Google Distributed Cloud lance une réparation sur un nœud si celui-ci répond à au moins une des conditions de la liste précédente.
La réparation draine le nœud non opérationnel et crée une VM. Si le drainage du nœud échoue pendant une heure, la réparation force le drainage et dissocie les disques gérés Kubernetes associés.
Si plusieurs nœuds sont non opérationnels dans le même MachineDeployment, la réparation n'est effectuée que sur un seul de ces nœuds à la fois.
Le nombre de réparations par heure pour un pool de nœuds est limité au maximum de :
- Trois
- Dix pour cent du nombre de nœuds du pool de nœuds
Activer la réparation de nœud et la vérification d'état sur un nouveau cluster
Dans le fichier de configuration de cluster d'administrateur ou d'utilisateur, définissez autoRepair.enabled
sur true
:
autoRepair: enabled: true
Passez aux étapes de création du cluster d'administrateur ou d'utilisateur.
Activer la réparation de nœud et la vérification d'état sur un cluster d'utilisateur existant
Dans votre fichier de configuration de cluster d'utilisateur, définissez autoRepair.enabled
sur true
:
Mettez à jour le cluster :
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
Activer la réparation de nœud et la vérification d'état sur un cluster d'administrateur existant
Dans votre fichier de configuration de cluster d'administrateur, définissez autoRepair.enabled
sur true
:
Mettez à jour le cluster :
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.
Afficher les journaux d'un vérificateur d'état
Répertoriez tous les pods du vérificateur d'état du cluster administrateur :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep cluster-health-controller
Le résultat est semblable à ceci :
kube-system cluster-health-controller-6c7df455cf-zlfh7 2/2 Running my-user-cluster cluster-health-controller-5d5545bb75-rtz7c 2/2 Running
Pour afficher les journaux d'un vérificateur d'état particulier, récupérez les journaux du conteneur cluster-health-controller
dans l'un des pods. Par exemple, pour obtenir les journaux de my-user-cluster
présentés dans le résultat précédent, exécutez la commande suivante :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster logs \ cluster-health-controller-5d5545bb75-rtz7c cluster-health-controller
Afficher des événements à partir d'un vérificateur d'état
Répertoriez tous les objets Cluster de votre cluster d'administrateur :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get clusters --all-namespaces
Le résultat est semblable à ceci :
default gke-admin-ldxh7 2d15h my-user-cluster my-user-cluster 2d12h
Pour afficher les événements associés à un cluster particulier, exécutez kubectl describe cluster
avec l'option --show-events
. Par exemple, pour afficher les événements de my-user-cluster
présentés dans le résultat précédent, exécutez la commande suivante :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster \ describe --show-events cluster my-user-cluster
Exemple de résultat :
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ValidationFailure 17s cluster-health-periodics-controller validator for Pod returned with status: FAILURE, reason: 1 pod error(s).
Désactiver la réparation des nœuds et la vérification d'état sur un cluster d'utilisateur
Dans votre fichier de configuration de cluster d'utilisateur, définissez autoRepair.enabled
sur false
:
Mettez à jour le cluster :
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
Désactiver la réparation des nœuds et la vérification d'état sur un cluster d'administrateur
Dans votre fichier de configuration de cluster d'administrateur, définissez autoRepair.enabled
sur false
:
Mettez à jour le cluster :
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
Déboguer la réparation automatique des nœuds lorsque le cluster avancé n'est pas activé
Vous pouvez examiner les problèmes liés à la réparation automatique des nœuds en décrivant les objets Machine et Nœud du cluster d'administrateur. Exemple :
Répertoriez les objets Machine :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get machines
Exemple de résultat :
default gke-admin-master-wcbrj default gke-admin-node-7458969ff8-5cg8d default gke-admin-node-7458969ff8-svqj7 default xxxxxx-user-cluster-41-25j8d-567f9c848f-fwjqt
Décrivez l'un des objets Machine :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine gke-admin-master-wcbrj
Dans la sortie, recherchez des événements provenant de cluster-health-controller
.
De même, vous pouvez répertorier et décrire des objets Nœud. Exemple :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes ... kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe node gke-admin-master-wcbrj
Déboguer la réparation automatique des nœuds lorsque le cluster avancé est activé
Vous pouvez examiner les problèmes liés à la réparation automatique des nœuds en décrivant les objets Machine et Nœud du cluster d'administrateur et du cluster correspondant, respectivement. Exemple :
Répertoriez les objets Machine :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get machines
Exemple de résultat :
NAMESPACE NAME NODEPOOL ci-1f6861fe28cac8fb390bc798927c717b 10.251.172.47 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.173.64 ci-1f6861fe28cac8fb390bc798927c717b-cp ci-1f6861fe28cac8fb390bc798927c717b 10.251.173.66 ci-1f6861fe28cac8fb390bc798927c717b-cp ci-1f6861fe28cac8fb390bc798927c717b 10.251.174.19 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.175.15 ci-1f6861fe28cac8fb390bc798927c717b-np ci-1f6861fe28cac8fb390bc798927c717b 10.251.175.30 ci-1f6861fe28cac8fb390bc798927c717b-cp kube-system 10.251.172.239 gke-admin-bnbp9-cp kube-system 10.251.173.39 gke-admin-bnbp9-cp kube-system 10.251.173.6 gke-admin-bnbp9-cp
Décrivez la machine correspondant à l'objet Machine:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine -n ci-1f6861fe28cac8fb390bc798927c717b 10.251.172.47
Dans la sortie, recherchez des événements provenant de auto-repair-controller
.
De même, vous pouvez répertorier et décrire des objets Nœud. Exemple :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes ... kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe node ci-1f6861fe28cac8fb390bc798927c717b-np
Réparation manuelle des nœuds lorsque le cluster avancé n'est pas activé
Nœud du plan de contrôle d'administrateur
Le nœud du plan de contrôle d'administration dispose d'une commande de réparation dédiée, car la réparation manuelle normale ne fonctionne pas.
Utilisez gkectl repair
admin-master
pour réparer le nœud du plan de contrôle d'administrateur.
Nœud du plan de contrôle du cluster d'utilisateur Controlplane V2
Les nœuds du plan de contrôle du cluster d'utilisateur Controlplane V2 sont gérés différemment des autres nœuds.
Comme pour les clusters d'utilisateurs kubeception, les objets Machine du plan de contrôle des clusters d'utilisateurs Controlplane V2 se trouvent dans le cluster d'administrateur. La réparation automatique des nœuds est couverte par la réparation automatique des nœuds du cluster d'administrateur.
Si vous rencontrez des problèmes avec un nœud qui ne sont pas couverts par la logique de réparation automatique du cluster d'administrateur, ou si vous n'avez pas activé la réparation automatique du cluster d'administrateur, vous pouvez effectuer une réparation manuelle. Cette action supprime et recrée le nœud.
Obtenez le nom de l'objet Machine correspondant au nœud :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG
: chemin d'accès au fichier kubeconfig du cluster d'administrateurUSER_CLUSTER_NAME
: nom du cluster d'utilisateur cible.
Ajoutez l'annotation
repair
à l'objet Machine :kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
Remplacez
MACHINE_NAME
par le nom de l'objet Machine.Supprimez l'objet Machine :
kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME
Recréez le nœud un par un pour un plan de contrôle HA, sinon le plan de contrôle risque de s'arrêter de manière inattendue.
Autres nœuds
Si vous rencontrez des problèmes avec un nœud qui ne sont pas couverts par la logique de réparation automatique, ou si vous n'avez pas activé la réparation automatique, vous pouvez effectuer une réparation manuelle. Cette action supprime et recrée le nœud.
Obtenez le nom de l'objet Machine correspondant au nœud :
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur ou d'utilisateur.
Ajoutez l'annotation repair
à l'objet Machine :
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
Remplacez MACHINE_NAME par le nom de l'objet Machine.
Supprimez l'objet Machine :
kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME
Réparation manuelle des nœuds lorsque le cluster avancé est activé
Nœud du plan de contrôle d'administrateur
La réparation manuelle du nœud du plan de contrôle d'administrateur n'est pas prise en charge
Nœud du plan de contrôle du cluster d'utilisateur / Nœuds de calcul
Obtenez le nom de l'objet Inventory Machine correspondant au nœud à l'aide de l'adresse IP du nœud pour faire correspondre les objets:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get inventorymachines
Remplacez les éléments suivants : ADMIN_CLUSTER_KUBECONFIG: chemin d'accès à votre fichier kubeconfig d'administrateur. USER_CLUSTER_NAME: nom du cluster d'utilisateur cible.
Ajoutez l'annotation force-remove
à l'objet Inventory Machine:
kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine MACHINE_NAME baremetal.cluster.gke.io/force-remove=true
Remplacez MACHINE_NAME par le nom de l'objet Machine.
Supprimez l'objet Machine d'inventaire:
kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine MACHINE_NAME
Recréez le nœud un par un pour un plan de contrôle HA, sinon le plan de contrôle risque de s'arrêter de manière inattendue.