Réparation automatique des nœuds et vérification de l'état

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 valeur true 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'état Available pendant environ 10 minutes.

  • La condition de nœud DiskPressure a la valeur true 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 valeur true pendant environ 10 minutes.

  • La condition de nœud DiskPressure a la valeur true 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.

  1. 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'administrateur
    • USER_CLUSTER_NAME: nom du cluster d'utilisateur cible.

  2. 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.

  3. 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.