Passer des nœuds en mode maintenance

Lorsque vous devez réparer ou gérer des nœuds, vous devez d'abord les passer en mode maintenance. Cela draine de manière optimale les pods et les charges de travail existants, à l'exclusion des pods système critiques tels que le serveur d'API. Le mode maintenance empêche également le nœud de recevoir de nouvelles attributions de pods. En mode maintenance, vous pouvez travailler sur vos nœuds sans risquer de perturber le trafic des pods.

Remarque :Lorsque vous mettez à niveau un cluster, Google Distributed Cloud utilise le flux du mode de maintenance décrit sur cette page pour drainer les nœuds avant leur mise à niveau. Pour en savoir plus sur le processus de mise à niveau, consultez la section Cycle de vie et étapes des mises à niveau du cluster.

Fonctionnement

Google Distributed Cloud permet de placer des nœuds en mode maintenance. Cette approche permet aux autres composants de cluster de savoir correctement que le nœud est en mode de maintenance. Lorsque vous placez un nœud en mode de maintenance, aucun pod supplémentaire ne peut être planifié sur le nœud et les pods existants sont arrêtés.

Au lieu d'utiliser le mode de maintenance, vous pouvez utiliser manuellement des commandes Kubernetes telles que kubectl cordon et kubectl drain sur un nœud spécifique.

Lorsque vous utilisez le processus en mode maintenance, Google Distributed Cloud effectue les opérations suivantes:

1.29

• Google Distributed Cloud ajoute le rejet baremetal.cluster.gke.io/maintenance:NoSchedule aux nœuds spécifiés pour empêcher la planification de nouveaux pods sur le nœud.

• Google Distributed Cloud utilise l'API Eviction pour évincer chaque pod. Cette méthode de drainage des nœuds respecte les PodDisruptionBudgets (PDB). Vous pouvez configurer des PDB pour protéger vos charges de travail en spécifiant un niveau d'interruption tolérable pour un ensemble de pods à l'aide des champs minAvailable et maxUnavailable. Ce procédé permet de mieux protéger les nœuds contre les interruptions de la charge de travail. Le drainage de nœuds basé sur l'éviction est disponible en disponibilité générale pour la version 1.29.

• Un délai avant expiration de 20 minutes est appliqué pour garantir que les nœuds ne restent pas bloqués dans l'attente de l'arrêt des pods. Les pods peuvent ne pas s'arrêter s'ils sont configurés pour tolérer tous les rejets ou s'ils disposent de finaliseurs. Google Distributed Cloud tente d'arrêter tous les pods, mais si le délai avant expiration est dépassé, le nœud passe en mode maintenance. Ce délai empêche les pods en cours d'exécution de bloquer les mises à niveau.

1.28 et versions antérieures

• Google Distributed Cloud ajoute le rejet baremetal.cluster.gke.io/maintenance:NoSchedule aux nœuds spécifiés pour empêcher la planification de nouveaux pods sur le nœud.

• Google Distributed Cloud ajoute le rejet baremetal.cluster.gke.io/maintenance:NoExecute. En agissant sur le rejet NoExecute, Google Distributed Cloud kube-scheduler arrête les pods et draine le nœud. Cette méthode de drainage des nœuds ne respecte pas les PDB.

• Un délai avant expiration de 20 minutes est appliqué pour garantir que les nœuds ne restent pas bloqués dans l'attente de l'arrêt des pods. Les pods peuvent ne pas s'arrêter s'ils sont configurés pour tolérer tous les rejets ou s'ils disposent de finaliseurs. Google Distributed Cloud tente d'arrêter tous les pods, mais si le délai avant expiration est dépassé, le nœud passe en mode maintenance. Ce délai empêche les pods en cours d'exécution de bloquer les mises à niveau.

Vidange avec éviction

Aucun changement de procédure n'est associé au passage au drainage de nœud basé sur l'éviction, et non au drainage basé sur le rejet. Cette option n'affecte que la logique de rapprochement.

Cette fonctionnalité n'est pas au même stade de lancement pour toutes les versions compatibles:

• 1.29: DG
• 1.28: Non disponible
• 1.16: Non disponible

Ordre de drainage

Avant la version 1.29, le drainage de nœud basé sur le rejet effectué par le service cloud distribué kube-scheduler de Google n'utilisait pas d'algorithme particulier pour drainer les pods d'un nœud. Avec le drainage de nœuds basé sur l'éviction, les pods sont évincés dans un ordre spécifique en fonction de la priorité. La priorité d'éviction est associée à des critères spécifiques au pod, comme indiqué dans le tableau suivant:

Ordre de drainage	Critères des pods (doivent correspondre à tous les critères) et
1	Les pods correspondant aux critères suivants sont évincés: Pods sans spec.prorityClassName Pods qui ne correspondent à aucun nom CSI (Container Storage Interface) connu Pods n'appartenant pas à un DaemonSet
2	Les pods correspondant aux critères suivants sont évincés: Pods appartenant à un DaemonSet Les pods ne comportent pas de PriorityClass Pods qui ne correspondent à aucun nom CSI (Container Storage Interface) connu
3	Les pods correspondant aux critères suivants sont évincés: Pods avec Spec.ProrityClassName Pods qui ne correspondent à aucun nom CSI (Container Storage Interface) connu L'ordre d'éviction des pods correspondants est basé sur PriorityClass.value, du plus bas au plus élevé.
4	Attendez que CSI nettoie les montages PV/PVC une fois les pods évincés. Utilisez Node.Status.VolumesInUse pour indiquer que tous les volumes sont nettoyés.
5	Les pods correspondant aux critères suivants sont évincés: Pods correspondant à un nom CSI (Container Storage Interface) connu Ces pods nécessitent toujours un drainage, car kubelet n'assure pas la compatibilité des mises à niveau sur place.

Étant donné que le drainage des nœuds basé sur une éviction respecte les PDB, les paramètres PDB peuvent bloquer le drainage des nœuds dans certaines circonstances. Pour obtenir des informations de dépannage sur le drainage du pool de nœuds, consultez la section Vérifier pourquoi un nœud présente l'état de drainage depuis longtemps.

Désactiver le drainage de nœuds basé sur l'éviction

Le drainage de nœuds basé sur l'éviction est activé par défaut pour les clusters à la version mineure 1.29 ou sur les clusters mis à niveau vers la version mineure 1.29. Si le drainage de nœuds basé sur l'éviction entraîne des problèmes lors des mises à niveau ou de la maintenance du cluster, vous pouvez revenir au drainage de nœuds basé sur le rejet en ajoutant l'annotation baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true à votre ressource de cluster.

Placer un nœud en mode de maintenance

Choisissez les nœuds que vous souhaitez passer en mode maintenance en spécifiant des plages d'adresses IP pour les nœuds sélectionnés sous maintenanceBlocks dans votre fichier de configuration de cluster. Les nœuds que vous choisissez doivent être prêts et opérationnels dans le cluster.

Pour passer des nœuds en mode maintenance, procédez comme suit :

1. Modifiez le fichier de configuration du cluster pour sélectionner les nœuds à passer en mode maintenance.

   Vous pouvez modifier le fichier de configuration avec l'éditeur de votre choix ou modifier directement la ressource personnalisée du cluster en exécutant la commande suivante :

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAMESPACE : espace de noms du cluster
   • CLUSTER_NAME : nom du cluster.

2. Ajoutez la section maintenanceBlocks au fichier de configuration du cluster pour spécifier une adresse IP unique ou une plage d'adresses pour les nœuds que vous souhaitez passer en mode maintenance.

   L'exemple suivant montre comment sélectionner plusieurs nœuds en spécifiant une plage d'adresses IP :

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. Enregistrez et appliquez la configuration de cluster mise à jour.

   Google Distributed Cloud commence à mettre les nœuds en mode maintenance.

4. Exécutez la commande suivante pour obtenir l'état des nœuds de votre cluster :

   kubectl get nodes --kubeconfig=KUBECONFIG
   

   Le résultat ressemble à ce qui suit :

   NAME                       STATUS   ROLES           AGE     VERSION
   user-anthos-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   Notez que les nœuds sont toujours programmables, mais les rejets empêchent la planification des pods (sans tolérance appropriée) sur le nœud.

5. Exécutez la commande suivante pour obtenir le nombre de nœuds en mode maintenance :

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   La réponse doit ressembler à l'exemple suivant:

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   La colonne UNDERMAINTENANCE de cet exemple montre qu'un nœud est en mode maintenance.

   Google Distributed Cloud ajoute également les rejets suivants aux nœuds lorsqu'ils sont en mode maintenance:

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

Supprimer un nœud du mode de maintenance

Pour supprimer des nœuds du mode maintenance, procédez comme suit :

1. Modifiez le fichier de configuration du cluster pour effacer les nœuds que vous souhaitez supprimer du mode maintenance.

   Vous pouvez modifier le fichier de configuration avec l'éditeur de votre choix ou modifier directement la ressource personnalisée du cluster en exécutant la commande suivante :

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAMESPACE : espace de noms du cluster
   • CLUSTER_NAME : nom du cluster.

2. Modifiez les adresses IP pour supprimer des nœuds spécifiques du mode maintenance ou supprimez la section maintenanceBlocks pour supprimer tous les nœuds du mode maintenance.

3. Enregistrez et appliquez la configuration de cluster mise à jour.

4. Utilisez les commandes kubectl pour vérifier l'état de vos nœuds.

Arrêter et redémarrer un cluster

S'il devient nécessaire de désactiver un cluster complet, suivez les instructions des sections suivantes pour arrêter un cluster et le restaurer en toute sécurité.

Arrêter un cluster

Si vous arrêtez un cluster qui gère des clusters d'utilisateur, vous devez d'abord arrêter tous les clusters d'utilisateur gérés. Les instructions suivantes s'appliquent à tous les types de clusters Google Distributed Cloud.

1. Vérifiez l'état de tous les nœuds du cluster:

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster.

   Le résultat ressemble à ce qui suit :

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   Si l'STATUS d'un nœud n'est pas Ready, nous vous recommandons vivement de résoudre les problèmes liés au nœud et de ne continuer que lorsque tous les nœuds sont à l'état Ready.

2. Si vous arrêtez un cluster d'utilisateur, vérifiez l'état des nœuds du cluster d'administrateur:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Remplacez ADMIN_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster de gestion.

   Les étapes suivantes dépendent du cluster d'administrateur. Si l'STATUS d'un nœud n'est pas Ready, nous vous recommandons vivement de résoudre les problèmes liés au nœud et de ne continuer que lorsque tous les nœuds sont à l'état Ready.

3. Vérifiez l'état du cluster que vous souhaitez arrêter:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME: nom du cluster que vous vérifiez.

   • ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster de gestion.

   Corrigez les problèmes signalés avant de continuer.

4. Pour le cluster que vous arrêtez, assurez-vous que tous les pods etcd sont en cours d'exécution:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster.

   Le résultat ressemble à ce qui suit :

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   Si la valeur STATUS d'un pod n'est pas Running, nous vous recommandons vivement de dépanner le pod et de ne continuer que lorsque tous les pods sont à l'état Running.

5. Effectuez une sauvegarde comme décrit dans la section Sauvegarder un cluster.

   Il est important d'effectuer une sauvegarde etcd avant d'arrêter votre cluster afin qu'il puisse être restauré si vous rencontrez des problèmes lors de son redémarrage. La corruption d'Etcd, les défaillances matérielles des nœuds, les problèmes de connectivité réseau et éventuellement d'autres conditions peuvent empêcher le cluster de redémarrer correctement.

6. Si vous arrêtez un cluster comportant des nœuds de calcul, mettez ces derniers en mode maintenance.

   Cette étape permet de réduire au minimum la quantité d'écritures dans etcd, ce qui réduit la probabilité qu'un grand nombre d'écritures etcd doive être rapprochées lors du redémarrage du cluster.

7. Passez les nœuds du plan de contrôle en mode maintenance.

   Cette étape empêche les écritures corrompues pour les charges de travail avec état lors de l'arrêt du nœud.

8. Arrêtez les nœuds du cluster dans l'ordre suivant:

   1. Nœuds de calcul
   2. Nœuds de l'équilibreur de charge du plan de contrôle

   3. Nœuds du plan de contrôle, en commençant par les followers etcd et en terminant par le leader etcd

      Si vous disposez d'un cluster à haute disponibilité, vous pouvez trouver le leader etcd en vous connectant à chaque nœud du plan de contrôle via SSH et en exécutant la commande etcdctl suivante:

      ETCDCTL_API=3 etcdctl \
          --cacert /etc/kubernetes/pki/etcd/ca.crt \
          --cert /etc/kubernetes/pki/etcd/server.crt \
          --key /etc/kubernetes/pki/etcd/server.key \
          --write-out=table endpoint status
      

      La réponse inclut une colonne IS LEADER, qui renvoie true si le nœud est le leader etcd.

   Remarque :Il est normal que le serveur d'API soit en panne une fois les followers etcd indisponibles. En effet, le serveur d'API ne peut pas diffuser de requêtes si le cluster etcd perd le quorum, ce qui est attendu lors de l'arrêt. Etcd récupère le quorum une fois que tous les nœuds du plan de contrôle sont de nouveau en ligne.

À ce stade, votre cluster est complètement arrêté. Après avoir effectué les opérations de maintenance nécessaires, vous pouvez redémarrer votre cluster comme décrit dans la section suivante.

Redémarrer le cluster

Procédez comme suit pour redémarrer un cluster entièrement arrêté.

1. Activez les machines de nœud dans l'ordre inverse de la séquence d'arrêt.

2. Supprimez les nœuds du plan de contrôle du mode maintenance.

   Pour obtenir des instructions, consultez la section Supprimer un nœud du mode maintenance.

   Remarque :Il n'est pas nécessaire de sortir les machines du mode maintenance une par une, mais il est recommandé de commencer avec un seul nœud, de vous assurer qu'il est opérationnel, puis d'augmenter progressivement le nombre de nœuds au fil du temps.

3. Supprimez les nœuds de calcul du mode maintenance.

4. Exécutez les vérifications de l'état du cluster pour vous assurer qu'il fonctionne correctement:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Si un problème, tel que le plantage en boucle d'etcd, empêche le cluster de redémarrer correctement, essayez de le restaurer à partir de la dernière sauvegarde saine connue. Pour obtenir des instructions, consultez la section Restaurer un cluster.

Mode de facturation et de maintenance

La facturation de Google Distributed Cloud est basée sur le nombre de processeurs virtuels de votre cluster pour les nœuds capables d'exécuter des charges de travail. Lorsque vous mettez un nœud en mode maintenance, les rejets NoExecute et NoSchedule sont ajoutés au nœud, mais ils ne désactivent pas la facturation. Après avoir mis un nœud en mode maintenance, marquez-le comme non programmable (kubectl cordon NODE_NAME). Une fois qu'un nœud est marqué comme non programmable, il et ses processeurs virtuels associés sont exclus de la facturation.

Important: L'arrêt d'un nœud ne modifie pas son état de facturation. Pour exclure un nœud de la facturation, effectuez l'une des actions suivantes :

• Supprimer un nœud individuel d'un pool de nœuds
• Supprimez un pool de nœuds du cluster.
• Mettez un nœud en mode maintenance et marquez-le comme non programmable pour le rendre non programmable.

Comme décrit sur la page des tarifs, vous pouvez utiliser kubectl pour afficher la capacité de processeurs virtuels (utilisée pour la facturation) de chacun de vos clusters d'utilisateur. La commande ne prend pas en compte si le nœud est programmable ou non. Elle fournit uniquement un nombre de processeurs virtuels par nœud.

Pour identifier le nombre de processeurs virtuels par nœud pour votre cluster d'utilisateur:

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

Remplacez USER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.