Name: Tremplin Numérique
Price range: $$$

Les nœuds Kubernetes nécessitent une maintenance occasionnelle. Vous pouvez mettre à jour le noyau du nœud, redimensionner sa ressource de calcul dans votre compte cloud ou remplacer des composants matériels physiques dans une installation auto-hébergée.

Les cordons et les drains Kubernetes sont deux mécanismes que vous pouvez utiliser pour vous préparer en toute sécurité aux temps d’arrêt des nœuds. Ils permettent aux charges de travail exécutées sur un nœud cible d’être replanifiées sur d’autres. Vous pouvez ensuite arrêter le nœud ou le supprimer de votre cluster sans affecter la disponibilité du service.

Sommaire

Application d’un cordon de nœud

Le cordonnage d’un nœud le marque comme indisponible pour le planificateur Kubernetes. Le nœud ne sera pas éligible pour héberger de nouveaux pods ajoutés par la suite à votre cluster.

Utilisez le kubectl cordon commande pour placer un cordon autour d’un nœud nommé :

$ kubectl cordon node-1
node/node-1 cordoned

Les pods existants déjà en cours d’exécution sur le nœud ne seront pas affectés par le cordon. Ils resteront accessibles et seront toujours hébergés par le Node en cordon.

Vous pouvez vérifier lesquels de vos nœuds sont actuellement bouclés avec le get nodes commande:

$ kubectl get nodes
NAME       STATUS                     ROLES                  AGE   VERSION
node-1     Ready,SchedulingDisabled   control-plane,master   26m   v1.23.3

Les nœuds en cordon apparaissent avec le SchedulingDisabled statut.

Vidange d’un nœud

L’étape suivante consiste à vider les pods restants du nœud. Cette procédure expulsera les pods afin qu’ils soient replanifiés sur d’autres nœuds de votre cluster. Les pods sont autorisés à se terminer correctement avant d’être supprimés de force du nœud cible.

Courir kubectl drain pour lancer une procédure de vidange. Spécifiez le nom du nœud que vous souscrivez pour la maintenance :

$ kubectl drain node-1
node/node-1 already cordoned
evicting pod kube-system/storage-provisioner
evicting pod default/nginx-7c658794b9-zszdd
evicting pod kube-system/coredns-64897985d-dp6lx
pod/storage-provisioner evicted
pod/nginx-7c658794b9-zszdd evicted
pod/coredns-64897985d-dp6lx evicted
node/node-1 evicted

La procédure de vidange boucle d’abord le nœud si vous n’en avez pas déjà placé un manuellement. Il supprimera ensuite les charges de travail Kubernetes en cours d’exécution en les replanifiant en toute sécurité vers d’autres nœuds de votre cluster.

Vous pouvez arrêter ou détruire le nœud une fois la vidange terminée. Vous avez libéré le nœud de ses responsabilités envers votre cluster. Le cordon donne l’assurance qu’aucune nouvelle charge de travail n’a été planifiée depuis la fin de la vidange.

Ignorer les périodes de grâce des pods

Les vidanges peuvent parfois prendre un certain temps si vos pods ont de longues périodes de grâce. Ce n’est peut-être pas idéal lorsque vous devez mettre un nœud hors ligne de toute urgence. Utilisez le --grace-period pour ignorer les périodes de grâce de résiliation du pod et forcer une éviction immédiate :

$ kubectl drain node-1 --grace-period 0

Cela doit être utilisé avec précaution – certaines charges de travail peuvent ne pas bien répondre si elles sont arrêtées sans qu’une chance de nettoyage leur soit offerte.

Résolution des erreurs de vidange

Les drains peuvent parfois entraîner une erreur en fonction des types de pod qui existent dans votre cluster. Voici deux problèmes courants avec leurs résolutions.

1. « Impossible de supprimer les pods non gérés par ReplicationController, ReplicaSet, Job ou StatefulSet »

Ce message apparaît si le nœud héberge des pods qui ne sont pas gérés par un contrôleur. Il fait référence aux pods qui ont été créés en tant qu’objets autonomes, où ils ne font pas partie d’une ressource de niveau supérieur comme un déploiement ou un ReplicaSet.

Kubernetes ne peut pas replanifier automatiquement ces pods « nus », donc les évincer les rendra indisponibles. Adressez manuellement ces pods avant d’effectuer la vidange ou utilisez le --force flag pour autoriser leur suppression :

$ kubectl drain node-1 --force

2. « Impossible de supprimer les pods gérés par DaemonSet »

Les pods qui font partie des ensembles de démons posent un défi aux expulsions. Les contrôleurs DaemonSet ne tiennent pas compte du statut planifiable de vos nœuds. La suppression d’un pod faisant partie d’un DaemonSet entraînera son retour immédiat, même si vous avez bouclé le nœud. Les opérations de vidange sont par conséquent abandonnées avec une erreur pour vous avertir de ce comportement.

Vous pouvez procéder à l’expulsion en ajoutant le --ignore-daemonsets drapeau. Cela expulsera tout le reste tout en ignorant tous les DaemonSets existants.

$ kubectl drain node-1 --ignore-daemonsets

Vous devrez peut-être utiliser cet indicateur même si vous n’avez pas créé vous-même de DaemonSets. Composants internes au sein du kube-system l’espace de noms pourrait utiliser les ressources DaemonSet.

Minimiser les temps d’arrêt avec les budgets de perturbation des pods

Le drainage d’un nœud ne garantit pas que vos charges de travail resteront accessibles tout au long. Vos autres nœuds auront besoin de temps pour honorer les demandes de planification et créer de nouveaux conteneurs.

Cela peut être particulièrement percutant si vous drainez plusieurs nœuds en peu de temps. Vider le premier nœud pourrait reprogrammer ses pods sur le deuxième nœud, qui est lui-même alors supprimé.

Les budgets de perturbation des pods sont un mécanisme pour éviter cette situation. Vous pouvez les utiliser avec Deployments, ReplicationControllers, ReplicaSets et StatefulSets.

Les objets ciblés par un budget d’interruption de pod sont garantis avoir un nombre spécifique de pods accessibles à tout moment. Kubernetes bloquera les drains de nœuds qui entraîneraient une baisse trop importante du nombre de pods disponibles.

Voici un exemple de PodDisruptionBudget Objet YAML :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: my-app

Cette politique exige qu’il y ait au moins quatre pods en cours d’exécution avec le app=my-app étiquette. Les drains de nœuds qui entraîneraient la planification de seulement trois pods seront évités.

Le niveau de perturbation autorisé est exprimé soit en maxUnavailable ou minAvailable champ. Un seul d’entre eux peut exister dans un seul objet Pod Disruption Budget. Chacun accepte un nombre absolu de pods ou un pourcentage relatif au nombre total de pods en pleine disponibilité :

minAvailable: 4 – Exiger qu’au moins quatre pods soient disponibles.
maxUnavailable: 50% – Autoriser jusqu’à la moitié du nombre total de pods à être indisponibles.

Ignorer les budgets de perturbation des pods

Les budgets d’interruption de pod sont un mécanisme qui assure la protection de vos charges de travail. Ils ne doivent pas être remplacés, sauf si vous devez immédiatement arrêter un nœud. La drain commande --disable-eviction flag fournit un moyen d’y parvenir.

$ kubectl drain node-1 --disable-eviction

Cela contourne le processus d’expulsion régulier du Pod. Les gousses seront directement supprimé au lieu de cela, en ignorant les budgets de perturbation appliqués.

Sauvegarder les nœuds

Une fois que vous avez terminé votre maintenance, vous pouvez remettre le nœud sous tension pour le reconnecter à votre cluster. Vous devez ensuite supprimer le cordon que vous avez créé pour marquer à nouveau le Node comme planifiable :

$ kubectl uncordon node-1
node/node-1 uncordoned

Kubernetes commencera à allouer de nouvelles charges de travail au nœud, le remettant en service actif.

Sommaire

La maintenance des nœuds Kubernetes ne doit pas être tentée tant que vous n’avez pas vidé les charges de travail existantes et établi un cordon. Ces mesures vous aident à éviter les temps d’arrêt inattendus lors de la maintenance de nœuds activement utilisés.

Les drains de base sont souvent adéquats si vous avez la capacité dans votre cluster de replanifier immédiatement vos charges de travail vers d’autres nœuds. Utilisez les budgets d’interruption de pod dans les situations où une disponibilité constante doit être garantie. Ils vous permettent de vous prémunir contre les temps d’arrêt involontaires lorsque plusieurs vidanges sont lancées simultanément.