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 permet de vider correctement 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 attributions 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 de mode de 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 d'éviction pour expulser 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 de perturbation acceptable 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 vidage des nœuds basé sur l'éviction est disponible en version GA 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 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, 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 bouton bascule n'affecte que la logique de réconciliation.

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 (doit correspondre à tous) et
1

Les pods qui répondent 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 qui répondent 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 qui répondent 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, de faible à élevé.
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 qui répondent 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 respecte les PDB, les paramètres PDB peuvent bloquer le drainage des nœuds dans certains cas. 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é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 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 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: 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 à 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-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 peuvent toujours être planifiés, mais que les rejets empêchent la planification 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é.

Arrêter un cluster

Si vous arrêtez un cluster qui gère des clusters d'utilisateurs, vous devez d'abord arrêter tous les clusters d'utilisateurs 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 la valeur 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 poursuivre que lorsque tous les nœuds sont Ready.

  2. Si vous arrêtez un cluster utilisateur, vérifiez l'état des nœuds du cluster 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 administrateur. Si la valeur 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 poursuivre 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 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 l'état STATUS d'un pod n'est pas Running, nous vous recommandons vivement de résoudre les problèmes liés au pod et de ne poursuivre que lorsque tous les pods sont Running.

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

    Il est important de créer une sauvegarde etcd avant d'arrêter votre cluster afin de pouvoir le restaurer en cas de problème lors du 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, placez-les 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. Placez 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. Éteignez 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é (HA), 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 la maintenance effectuée, 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 arrêté.

  1. Allumez les machines de nœuds 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 Supprimer un nœud du mode de maintenance.

  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 cycle de plantage d'etcd, empêche le cluster de redémarrer correctement, essayez de restaurer le cluster à partir de la dernière sauvegarde satisfaisante. Pour obtenir des instructions, consultez Restaurer un cluster.

Mode de facturation et de maintenance

La facturation pour Google Distributed Cloud est basée sur le nombre de vCPU de votre cluster pour les nœuds capables d'exécuter des charges de travail. Lorsque vous placez 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 indiqué 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 utilisateur. La commande ne tient pas compte de la possibilité ou non de planifier le nœud. Elle fournit uniquement le nombre de vCPU par nœud.

Pour identifier le nombre de vCPU par nœud pour votre cluster d'utilisateurs :

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