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. Cette opération draine en douceur les pods et les charges de travail existants, à l'exception des pods système critiques tels que le serveur d'API. Le mode maintenance empêche également le nœud de recevoir de nouvelles affectations de pods. En mode maintenance, vous pouvez travailler sur vos nœuds sans risque de perturber le trafic de pod.

Fonctionnement

Google Distributed Cloud permet de placer des nœuds en mode de 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 du mode maintenance, Google Distributed Cloud effectue les opérations suivantes :

1,29

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

  • Google Distributed Cloud utilise l'API d'éviction 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. Cette méthode de drainage des nœuds offre une meilleure protection contre les interruptions de la charge de travail. Le drainage des nœuds basé sur l'éviction est disponible en version DG pour la version 1.29.

  • Un délai d'expiration de 20 minutes est appliqué pour garantir que les nœuds ne restent pas bloqués à attendre 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 est mis en mode de maintenance. Ce délai avant expiration empêche les pods d'exécuter des mises à niveau bloquantes.

1.28 et versions antérieures

  • Google Distributed Cloud adds the baremetal.cluster.gke.io/maintenance:NoSchedule rejet 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, le kube-scheduler de Google Distributed Cloud arrête les pods et vide le nœud. Cette méthode de drainage des nœuds n'honore pas les PDB.

  • Un délai d'expiration de 20 minutes est appliqué pour garantir que les nœuds ne restent pas bloqués à attendre 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 est mis en mode de maintenance. Ce délai avant expiration empêche les pods d'exécuter des mises à niveau bloquantes.

Drainage basée sur l'éviction

Il n'y a pas de modifications de procédure associées au passage à l'évacuation des nœuds basée sur l'éviction à partir de l'évacuation basée sur le rejet. Le changement 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 kube-scheduler de Google Distributed Cloud n'utilise pas d'algorithme particulier pour vider les pods d'un nœud. Avec le drainage de nœud 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 de pod spécifiques, comme indiqué dans le tableau suivant :

Ordre de drainage Critères de pod (doivent tous correspondre) 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 qui n'appartiennent pas à un DaemonSet
2

Les pods correspondant aux critères suivants sont évincés :

  • Pods appartenant à un DaemonSet
  • Les pods qui ne disposent 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 haut.
4

Attendez que CSI nettoie les points de montage PV/PVC une fois que tous les pods ont été é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 doivent toujours être drainés, car kubelet ne fournit pas de compatibilité avec la mise à niveau sur place.

Étant donné que le drainage des nœuds basé sur l'éviction honore 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 Vérifier pourquoi un nœud est à l'état "Drainage" depuis longtemps.

Délai pour le drainage basé sur l'éviction

Lorsque vous passez des nœuds en mode maintenance, le système applique un délai avant expiration par défaut de 20 minutes (1 200 secondes) pour drainer les nœuds. Lorsque le délai avant expiration est écoulé, tous les pods qui ne tolèrent pas le mode maintenance sont évincés et le nœud est mis en mode maintenance. À partir de la version 1.16, vous pouvez ajouter l'annotation baremetal.cluster.gke.io/maintenance-mode-deadline-seconds à votre ressource de cluster pour ajuster la durée du délai avant expiration. Par exemple, pour modifier le délai avant expiration à 10 minutes, ajoutez l' baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600" annotation à votre ressource de cluster.

Le drainage basé sur l'éviction peut parfois dépasser le délai spécifié par maintenance-mode-deadline-seconds. Si les pods sont bloqués à l'état d'arrêt après le délai avant expiration, n'utilisez pas kubectl avec les indicateurs --grace-period=0 --force pour les supprimer de force, car cela peut entraîner une corruption des données ou des problèmes de split-brain pour les applications avec état. Redémarrez plutôt les nœuds avec des pods avec état bloqués.

Si vous avez besoin d'une aide supplémentaire, contactez

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

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

Pour restaurer le comportement par défaut du drainage des nœuds basé sur l'éviction, supprimez complètement l'annotation. Définir l'annotation sur false ne réactive pas le comportement par défaut.

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 à passer 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-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600

    Notez que les nœuds sont toujours programmables, mais les rejets empêchent la programmation de 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 devrait ressembler à ceci :

    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 placés 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

Si vous devez arrêter un cluster complet, suivez les instructions des sections suivantes pour arrêter un cluster et le redémarrer en toute sécurité.

Éteindre 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 le STATUS d'un nœud n'est pas Ready, nous vous recommandons vivement de dépanner le nœud et de ne continuer que lorsque tous les nœuds sont 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 du fichier kubeconfig du cluster de gestion.

    Les étapes suivantes dépendent du cluster d'administrateur. Si le STATUS pour un nœud n'est pas Ready, nous vous recommandons vivement de dépanner le nœud et de ne continuer que lorsque tous les nœuds sont 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 tous 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 le 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 Running.

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

    Il est important d'effectuer une sauvegarde etcd avant d'arrêter votre cluster afin de pouvoir le restaurer en cas de problème 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 d'autres conditions peuvent empêcher le redémarrage correct du cluster.

  6. Si vous arrêtez un cluster avec des nœuds de calcul, passez les nœuds de calcul en mode maintenance.

    Cette étape réduit le nombre d'écritures dans etcd, ce qui réduit la probabilité qu'une grande quantité d'écritures etcd doivent être réconcilié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. Mettez hors tension les nœuds du cluster dans l'ordre suivant :

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

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

      Si vous disposez d'un cluster à haute disponibilité, vous pouvez trouver le leader etcd en utilisant SSH pour vous connecter à chaque nœud du plan de contrôle 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 la variante optimale etcd.

À ce stade, votre cluster est complètement arrêté. Une fois que vous avez effectué la maintenance nécessaire, 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 qui a été complètement mis hors tension.

  1. Mettez sous tension les machines de nœud dans l'ordre inverse de la séquence de mise hors tension.

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

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

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

  4. Exécutez des 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 qu'un crashlooping etcd, empêche le redémarrage correct du cluster, essayez de le restaurer à partir de la dernière bonne sauvegarde connue. Pour obtenir des instructions, consultez Restaurer un cluster.

Facturation et mode maintenance

La facturation de Google Distributed Cloud est basée sur le nombre de processeurs virtuels dont dispose votre cluster pour les nœuds capables d'exécuter des charges de travail. Lorsque vous passez 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 placé un nœud en mode maintenance, marquez-le comme non programmables via la commande cordon (kubectl cordon NODE_NAME). Une fois qu'un nœud est marqué comme non programmable, le nœud et les vCPU associés sont exclus de la facturation.

Comme décrit sur la page des tarifs, vous pouvez utiliser kubectl pour afficher la capacité du processeur virtuel (utilisée pour la facturation) de chacun de vos clusters d'utilisateur. La commande ne tient pas compte du fait que le nœud est programmable ou non. Elle ne fournit qu'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.