Gestion des nœuds Kubernetes : ajout, maintenance, drain et autoscaling

La gestion des nœuds Kubernetes constitue une compétence fondamentale pour tout administrateur de cluster en production. Avec 82% des utilisateurs de conteneurs qui exécutent Kubernetes en production et une moyenne de 20+ clusters par organisation, maîtriser les opérations de drain, cordon et autoscaling devient indispensable. Ce guide vous accompagne étape par étape dans la formation gestion des nœuds Kubernetes, de l'ajout d'un worker node jusqu'à la configuration de l'autoscaling automatique.

TL;DR : Pour gérer efficacement vos nœuds Kubernetes, utilisez kubectl cordon pour empêcher le scheduling, kubectl drain pour évacuer les pods avant maintenance, et configurez le Cluster Autoscaler pour ajuster automatiquement la capacité. Chaque opération doit être vérifiée avec kubectl get nodes et kubectl describe node.

Ces compétences sont au cœur de la formation LFS458 Administration Kubernetes.

Prérequis : environnement et outils nécessaires

Avant de commencer ce guide pratique, assurez-vous de disposer des éléments suivants :

Infrastructure :

Un cluster Kubernetes fonctionnel (v1.28+)
Accès SSH aux nœuds du cluster
Droits administrateur (ClusterRole cluster-admin)

Outils installés :

# Vérifier la version de kubectl
kubectl version --client
# Client Version: v1.29.0

# Vérifier l'accès au cluster
kubectl cluster-info
# Kubernetes control plane is running at https://192.168.1.10:6443

Connaissances préalables :

Compréhension de l'architecture du control plane Kubernetes
Familiarité avec les concepts de base (consultez Kubernetes les fondamentaux)

À retenir : Sans accès cluster-admin, vous ne pourrez pas effectuer les opérations de drain ou modifier les taints des nœuds. Vérifiez vos permissions avec kubectl auth can-i drain nodes.

Étape 1 : Ajouter un nouveau nœud worker au cluster

L'ajout d'un nœud worker s'effectue en trois phases : préparation du serveur, génération du token de join, et vérification de l'intégration.

1.1 Préparer le nouveau serveur

Installez les dépendances sur le nouveau nœud :

# Désactiver le swap (obligatoire pour Kubernetes)
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# Installer containerd
sudo apt-get update && sudo apt-get install -y containerd

# Configurer containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo systemctl restart containerd

1.2 Générer le token de join depuis le control plane

Sur le nœud master, créez un nouveau token :

kubeadm token create --print-join-command
# Résultat attendu :
# kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \
#     --discovery-token-ca-cert-hash sha256:xyz123...

1.3 Exécuter la commande join sur le worker

Sur le nouveau nœud worker :

sudo kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:xyz123...
# [preflight] Running pre-flight checks
# [kubelet-start] Starting the kubelet
# This node has joined the cluster

Vérification depuis le master :

kubectl get nodes
# NAME      STATUS   ROLES           AGE   VERSION
# master    Ready    control-plane   30d   v1.29.0
# worker1   Ready    <none>          25d   v1.29.0
# worker2   Ready    <none>          10s   v1.29.0

Pour une installation complète multi-nœuds, consultez le guide d'installation avec kubeadm.

Étape 2 : Utiliser cordon pour isoler un nœud

La commande kubectl cordon marque un nœud comme non-schedulable. Les pods existants continuent de fonctionner, mais aucun nouveau pod ne sera placé sur ce nœud.

2.1 Marquer un nœud comme non-schedulable

kubectl cordon worker2
# node/worker2 cordoned

Vérifier l'état du nœud :

kubectl get nodes
# NAME      STATUS                     ROLES           AGE   VERSION
# master    Ready                      control-plane   30d   v1.29.0
# worker1   Ready                      <none>          25d   v1.29.0
# worker2   Ready,SchedulingDisabled   <none>          1h    v1.29.0

2.2 Examiner les taints appliquées

kubectl describe node worker2 | grep -A5 Taints
# Taints:             node.kubernetes.io/unschedulable:NoSchedule

À retenir : Le cordon est idéal pour une maintenance planifiée. Les pods existants ne sont pas impactés, ce qui permet de préparer la maintenance sans interruption de service.

2.3 Restaurer le scheduling

Utilisez uncordon pour réactiver le nœud :

kubectl uncordon worker2
# node/worker2 uncordoned

kubectl get nodes worker2
# NAME      STATUS   ROLES    AGE   VERSION
# worker2   Ready    <none>   1h    v1.29.0

Étape 3 : Effectuer un drain sécurisé pour maintenance

Le kubectl drain évacue tous les pods d'un nœud avant une maintenance. Cette opération est essentielle pour la maintenance noeuds Kubernetes production.

3.1 Drain standard avec options de sécurité

kubectl drain worker2 --ignore-daemonsets --delete-emptydir-data
# node/worker2 cordoned
# evicting pod default/nginx-deployment-abc123
# evicting pod kube-system/coredns-xyz789
# pod/nginx-deployment-abc123 evicted
# pod/coredns-xyz789 evicted
# node/worker2 drained

Options essentielles :

Option	Description
`--ignore-daemonsets`	Ignore les DaemonSets (ne peuvent pas être reschedulés)
`--delete-emptydir-data`	Supprime les données emptyDir
`--force`	Force l'éviction des pods standalone
`--grace-period=30`	Délai de grâce pour l'arrêt des pods
`--timeout=300s`	Timeout de l'opération

3.2 Gérer les PodDisruptionBudgets

Les PodDisruptionBudgets (PDB) peuvent bloquer un drain :

kubectl drain worker2 --ignore-daemonsets
# error: cannot delete pods with local storage, evicting pods with local storage may cause data loss
# error: unable to drain node "worker2" due to PodDisruptionBudget

Vérifier les PDB :

kubectl get pdb -A
# NAMESPACE   NAME           MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
# default     nginx-pdb      2               N/A               0                     10d

Configurez les PDB uniquement pour les workloads critiques.

3.3 Vérification post-drain

kubectl get pods -o wide | grep worker2
# (aucun résultat - tous les pods ont été évacués)

kubectl get nodes worker2
# NAME      STATUS                     ROLES    AGE   VERSION
# worker2   Ready,SchedulingDisabled   <none>   1h    v1.29.0

À retenir : Toujours vérifier les PDB avant un drain planifié. Un drain bloqué peut retarder une maintenance critique et créer des situations d'urgence.

Étape 4 : Configurer l'autoscaling des nœuds

L'autoscaling cluster Kubernetes nodes permet d'adapter automatiquement la capacité du cluster à la charge. Selon ScaleOps, 65%+ des workloads utilisent moins de la moitié de leurs ressources allouées.

4.1 Installer le Cluster Autoscaler

Déployer le Cluster Autoscaler (exemple AWS EKS) :

kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

Configurer les paramètres :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: cluster-autoscaler
        command:
        - ./cluster-autoscaler
        - --cloud-provider=aws
        - --nodes=2:10:my-node-group
        - --scale-down-delay-after-add=10m
        - --scale-down-unneeded-time=10m
        - --skip-nodes-with-local-storage=false

4.2 Vérifier le fonctionnement

kubectl get pods -n kube-system -l app=cluster-autoscaler
# NAME                                  READY   STATUS    RESTARTS   AGE
# cluster-autoscaler-7c4d5f8d9-abcde    1/1     Running   0          5m

kubectl logs -n kube-system -l app=cluster-autoscaler --tail=20
# I0215 10:30:00.123456  1 scale_up.go:300] Scaled up node group my-node-group: 3 -> 4

La formation LFS458 couvre en détail la configuration de l'autoscaling pour différents cloud providers.

4.3 Configurer les métriques de scaling

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

kubectl apply -f nginx-hpa.yaml
kubectl get hpa
# NAME        REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
# nginx-hpa   Deployment/nginx   45%/70%   3         10        3          1m

Étape 5 : Mettre à niveau un nœud sans interruption

La mise à niveau des nœuds fait partie de la gestion noeuds Kubernetes drain cordon en production.

5.1 Processus de mise à niveau rolling

# 1. Drainer le nœud
kubectl drain worker2 --ignore-daemonsets --delete-emptydir-data

# 2. Effectuer la maintenance (mise à jour OS, kubelet, etc.)
sudo apt-get update && sudo apt-get upgrade -y kubelet kubeadm
sudo systemctl restart kubelet

# 3. Vérifier la version
kubectl get nodes worker2
# NAME      STATUS                     ROLES    AGE   VERSION
# worker2   Ready,SchedulingDisabled   <none>   30d   v1.29.1

# 4. Réactiver le nœud
kubectl uncordon worker2

5.2 Vérification de santé post-maintenance

kubectl get nodes -o wide
# Tous les nœuds doivent être Ready

kubectl get pods -A -o wide | grep -v Running
# Aucun pod ne doit être en état non-Running

Pour approfondir les aspects réseau de votre cluster, consultez le guide sur la configuration réseau CNI, Services et Ingress.

Dépannage : problèmes courants et solutions

Le drain reste bloqué

Symptôme : La commande kubectl drain ne se termine pas.

kubectl drain worker2 --ignore-daemonsets --timeout=60s
# evicting pod default/stuck-pod
# error: timed out waiting for pod to be deleted

Solution :

# Identifier le pod bloquant
kubectl get pods -o wide | grep worker2

# Forcer la suppression si nécessaire
kubectl delete pod stuck-pod --force --grace-period=0

# Réessayer le drain
kubectl drain worker2 --ignore-daemonsets --force

Le nœud reste NotReady après maintenance

Diagnostic :

kubectl describe node worker2 | grep -A10 Conditions
# Type             Status
# MemoryPressure   False
# DiskPressure     False
# PIDPressure      False
# Ready            False

# Vérifier les logs kubelet
sudo journalctl -u kubelet -f

Solution courante :

sudo systemctl restart kubelet
sudo systemctl restart containerd

À retenir : Documentez chaque maintenance dans un runbook. L'écosystème évolue constamment, vos procédures doivent suivre.

L'autoscaler ne déclenche pas de scale-up

Vérification :

kubectl describe configmap cluster-autoscaler-status -n kube-system
# Vérifier les raisons de non-scaling

kubectl get events -n kube-system | grep autoscaler

Pour une gestion avancée de vos nœuds et la préparation à la certification, explorez l'Administration cluster Kubernetes et les techniques de backup etcd.

Prochaines étapes : valider vos compétences

La gestion des nœuds Kubernetes représente une compétence clé pour tout administrateur système Kubernetes certification CKAD. Avec 104 000 personnes ayant passé le CKA et une croissance de 49% par an, ces certifications valident votre expertise auprès des employeurs.

Comme le confirme un CTO d'entreprise : « Just given the capabilities that exist with Kubernetes, and the company's desire to consume more AI tools, we will use Kubernetes more in future. »

Formations recommandées :

LFS458 Administration Kubernetes : 4 jours pour maîtriser l'administration de clusters et préparer le CKA
LFD459 Kubernetes pour les développeurs : 3 jours orientés développement applicatif et CKAD
Kubernetes les fondamentaux : 1 journée pour découvrir les concepts essentiels. Pour approfondir, consultez notre formation administration cluster kubernetes paris.

Pour explorer l'ensemble des compétences Kubernetes, consultez le Guide complet Formation Kubernetes.

Points clés