Routine d'exploitation Kubernetes : quotidien, hebdomadaire et mensuel

Un cluster Kubernetes sain est un cluster surveillé régulièrement. Les incidents les plus coûteux ne viennent pas de pannes soudaines mais de dérives lentes : pods en échec ignorés, jobs orphelins qui s’accumulent, certificats qui expirent silencieusement. Ce guide structure les vérifications et actions récurrentes d’un admin Kubernetes en trois rythmes — quotidien, hebdomadaire et mensuel — pour transformer l’administration réactive en exploitation préventive.

Ce que vous allez apprendre

• Structurer une vérification matinale en 5 minutes
• Identifier les pods et ressources en échec avant qu’ils ne causent un incident
• Planifier le nettoyage hebdomadaire des ressources orphelines (jobs, ReplicaSets, pression disque)
• Contrôler les certificats et les quotas chaque mois
• Organiser ces tâches avec une checklist actionnable par fréquence

Prérequis

• Un cluster Kubernetes en production (v1.28+)
• kubectl configuré avec des droits d’administration
• Avoir suivi le guide Observer la santé du cluster
• Accès aux métriques via kubectl top (metrics-server installé)

Quotidien — vérification matinale en 5 minutes

Chaque matin (ou à chaque début de service), ces 5 commandes donnent une vision immédiate de l’état du cluster. L’objectif : détecter toute anomalie avant qu’elle ne devienne un incident.

1. Santé des nœuds : tous les nœuds doivent être Ready.

   kubectl get nodes

   Un nœud NotReady ou SchedulingDisabled nécessite une investigation immédiate. Vérifiez si une maintenance est en cours.

2. Santé de l’API server : le cluster doit répondre positivement à toutes les vérifications internes.

   kubectl get --raw='/readyz?verbose' | grep -E '\[.\]|readyz'

   Tous les checks doivent afficher [+]. Un [-] signale un composant dégradé (etcd, informer-sync, etc.).

3. Pods en échec : identifier les pods qui ne tournent pas correctement.

   kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded | head -30

   Les pods en Pending, Failed ou CrashLoopBackOff apparaissent ici. Priorisez ceux des namespaces système (kube-system, monitoring).

4. Consommation des ressources : repérer les nœuds sous pression.

   kubectl top nodes

   Les seuils 80% CPU et 85% mémoire sont des repères opérationnels pour attirer l’attention, pas les seuils réels d’éviction du kubelet. Les évictions se déclenchent sur des signaux comme memory.available, nodefs.available ou imagefs.available (voir la section espace disque plus bas).

5. Événements récents : les warnings des dernières heures.

   kubectl get events -A --sort-by='.lastTimestamp' --field-selector type=Warning | tail -20

   Les événements Warning récurrents signalent souvent un problème sous-jacent : image introuvable, probe en échec, quota dépassé.

Automatiser la vérification matinale

Regroupez ces commandes dans un script cluster-health.sh ou un alias shell. L’objectif est de passer ces 5 vérifications en moins de 5 minutes chaque matin, sans réfléchir à la syntaxe.

Hebdomadaire — ressources orphelines et pression disque

Certaines dérives ne se voient pas au jour le jour mais s’accumulent sur la semaine. Planifiez ces vérifications une fois par semaine.

Pods et Jobs terminés

Des pods Succeeded ou Failed peuvent s’accumuler dans l’API, notamment pour les Jobs et certains workflows batch. Leur cycle de vie exact dépend du contrôleur qui les a créés et des mécanismes de nettoyage associés.

# Compter les pods terminés
kubectl get pods -A --field-selector=status.phase==Succeeded --no-headers | wc -l
kubectl get pods -A --field-selector=status.phase==Failed --no-headers | wc -l

Nettoyage automatique plutôt que manuel

Évitez le nettoyage manuel systématique des pods terminés avec kubectl delete pods --field-selector=.... Les pods terminés peuvent être utiles pour le diagnostic à court terme. Préférez configurer ttlSecondsAfterFinished sur les Jobs pour un nettoyage automatique après un délai défini. Ne supprimez manuellement les pods Failed ou Succeeded qu’après analyse ou dans le cadre d’une politique de rétention claire.

Les Jobs et CronJobs créent des pods à chaque exécution. Sans configuration de rétention, ils s’accumulent.

# Lister les CronJobs et leur historique
kubectl get cronjobs -A

# Voir les Jobs terminés
kubectl get jobs -A --field-selector=status.successful=1 --no-headers | wc -l

Configurez spec.successfulJobsHistoryLimit et spec.failedJobsHistoryLimit dans vos CronJobs pour limiter automatiquement l’historique (défaut : 3 succès, 1 échec). Pour les Jobs ponctuels, le contrôleur TTL-after-finished (stable depuis Kubernetes 1.23) supprime automatiquement les Jobs terminés après le délai défini par .spec.ttlSecondsAfterFinished.

ReplicaSets orphelins

Les rolling updates créent de nouveaux ReplicaSets à chaque déploiement. Kubernetes conserve un historique (par défaut : 10 révisions via spec.revisionHistoryLimit). Vérifiez que ce paramètre est raisonnable :

# Compter les ReplicaSets avec 0 répliques (anciennes révisions)
kubectl get rs -A --no-headers | awk '$3 == 0 && $4 == 0' | wc -l

Pour les clusters avec des déploiements fréquents, réduire revisionHistoryLimit à 3 ou 5 économise des objets dans etcd.

Quotas et limites

Les ResourceQuota et LimitRange évitent qu’un namespace ne consomme toutes les ressources du cluster. Vérifiez leur utilisation chaque semaine.

# Voir les quotas et leur consommation
kubectl get resourcequota -A

# Détail d'un quota
kubectl describe resourcequota -n production

Un quota proche de sa limite (Used ≈ Hard) signifie que les prochains déploiements dans ce namespace échoueront. Anticipez en augmentant le quota ou en nettoyant les ressources inutilisées.

Pression disque

L’espace disque des nœuds est une ressource critique souvent oubliée. Les images de conteneurs, les logs et les volumes éphémères s’accumulent.

Le kubelet surveille plusieurs seuils d’éviction (configurables) :

Signal	Seuil par défaut	Conséquence
memory.available	100Mi	Le kubelet évince des pods
nodefs.available	10%	Le kubelet évince des pods
imagefs.available	15%	Le kubelet déclenche le garbage collection des images
nodefs.inodesFree	5%	Le kubelet évince des pods

Glissez pour voir

Si kubectl describe node affiche la condition DiskPressure: True, le nœud a atteint un seuil d’éviction. Le kubelet va supprimer des images inutilisées et évincer des pods par ordre de QoS (BestEffort en premier).

Garbage collection automatique des images

Le kubelet réalise déjà un garbage collection automatique des images quand les seuils imagefs.available sont atteints. Le nettoyage manuel avec crictl rmi --prune doit rester une action ciblée en cas de pression disque avérée ou de politique d’exploitation spécifique, pas une tâche régulière par défaut.

En cas de pression disque confirmée (avec containerd) :

# Sur le nœud (via SSH) — action ciblée, pas une routine
sudo crictl images | grep -v "IMAGE ID"
sudo crictl rmi --prune

Mensuel — certificats et tendances capacité

Les vérifications mensuelles portent sur des éléments à durée de vie plus longue : certificats, tendances de consommation, backlog de mises à jour.

Certificats du plan de contrôle (kubeadm)

Si votre cluster est déployé avec kubeadm, les certificats clients des composants du plan de contrôle expirent par défaut après 1 an. Vérifiez leur état :

# Sur un nœud control plane
sudo kubeadm certs check-expiration

Renouvelez-les avant expiration :

sudo kubeadm certs renew all

Après le renouvellement

Après renouvellement des certificats kubeadm, redémarrez les composants concernés du control plane (kube-apiserver, kube-controller-manager, kube-scheduler) selon votre méthode d’exploitation. Sur un cluster kubeadm en static pods, cela passe généralement par un redémarrage contrôlé des pods statiques — ne supprimez pas définitivement leurs manifests de /etc/kubernetes/manifests/, car le kubelet ne les régénère pas de lui-même.

Certificats TLS des Ingress (cert-manager)

Si vous utilisez cert-manager, vérifiez l’état des Certificate :

kubectl get certificates -A

La colonne READY doit être True et EXPIRATION doit être dans le futur. Un certificat False mérite une investigation : log du pod cert-manager, challenge DNS/HTTP en erreur, secret manquant.

Tendances capacité

Faites un point mensuel sur la consommation globale du cluster :

kubectl top nodes

Comparez avec les mois précédents. Une tendance à la hausse régulière signale un besoin d’ajuster la capacité (ajout de nœuds, optimisation des requests/limits, nettoyage de workloads inutilisés).

Checklist récapitulative par fréquence

Cette table résume l’ensemble des vérifications en un seul endroit. Chaque ligne correspond à une action concrète, classée par rythme d’intervention.

Fréquence	Vérification	Commande clé	Action si problème
Quotidienne	Nœuds Ready	kubectl get nodes	Investiguer nœud NotReady
Quotidienne	API server sain	kubectl get --raw='/readyz?verbose'	Vérifier logs composant [-]
Quotidienne	Pods en échec	kubectl get pods -A --field-selector=...	Investiguer ou redémarrer
Quotidienne	Consommation ressources	kubectl top nodes	Investiguer si repères opérationnels dépassés
Quotidienne	Événements Warning	kubectl get events -A ...	Identifier patterns récurrents
Hebdomadaire	Pods/Jobs terminés	kubectl get pods --field-selector=status.phase==Succeeded	Configurer TTL, nettoyer si nécessaire après analyse
Hebdomadaire	ReplicaSets orphelins	kubectl get rs -A	Ajuster revisionHistoryLimit
Hebdomadaire	Quotas namespace	kubectl get resourcequota -A	Ajuster si proche limite
Hebdomadaire	Pression disque	kubectl describe node (DiskPressure)	Nettoyage ciblé si confirmé
Mensuelle	Certificats control plane	kubeadm certs check-expiration	Renouveler si < 30 jours
Mensuelle	Certificats Ingress	kubectl get certificates -A	Vérifier cert-manager
Mensuelle	Tendances capacité	kubectl top nodes (historique)	Planifier ajustements

Glissez pour voir

Quand escalader

Toutes les anomalies ne nécessitent pas une action immédiate. Voici un guide de priorisation pour décider de l’urgence d’intervention.

Situation	Niveau	Action
1 pod applicatif en CrashLoopBackOff	Normal	Diagnostic dans la journée
Problème persistant dans kube-system (DNS, CNI, kube-proxy, stockage)	Urgent	Investigation prioritaire — composant cœur du cluster
Nœud NotReady	Urgent	Vérifier connectivité, kubelet, disque
readyz retourne un [-]	Critique	Investiguer immédiatement — composant dégradé
DiskPressure: True sur un nœud	Urgent	Nettoyage ciblé, vérifier logs/volumes
Certificat expire dans < 7 jours	Critique	Renouveler immédiatement
Quota namespace proche de la limite	Normal	Planifier augmentation ou nettoyage

Glissez pour voir

Nuance sur kube-system

Un pod en échec dans kube-system n’est pas toujours critique. Il peut s’agir d’un ancien pod de Job, d’un addon non essentiel ou d’un redémarrage transitoire sans impact. Concentrez l’investigation sur les composants cœur : CoreDNS, le CNI, kube-proxy, metrics-server, le driver de stockage.

De la checklist au monitoring

Cette checklist manuelle est un filet de sécurité. En production industrialisée, automatisez ces vérifications avec des alertes Prometheus / Alertmanager. La routine manuelle reste utile pour les petits clusters ou comme complément au monitoring.

Dépannage

Symptôme	Cause probable	Solution
kubectl top nodes ne fonctionne pas	metrics-server absent ou mal configuré	Installer metrics-server avec --kubelet-insecure-tls si auto-signé
Pods en Evicted qui s’accumulent	Pression disque ou mémoire sur un nœud	Vérifier conditions du nœud (DiskPressure, MemoryPressure). Nettoyage ciblé si confirmé
Events FailedScheduling récurrents	Ressources insuffisantes ou taints non tolérées	Vérifier requests/limits, taints, et nombre de nœuds disponibles
kubeadm certs check-expiration échoue	Cluster non déployé avec kubeadm	Consulter la documentation de votre outil de déploiement (kubespray, RKE2, etc.)
Quota dépassé, déploiement refusé	ResourceQuota atteint dans le namespace	kubectl describe resourcequota -n <ns> pour voir l’utilisation

Glissez pour voir

À retenir

• Un cluster sain se surveille régulièrement selon trois rythmes : quotidien (5 min), hebdomadaire (revue des ressources orphelines) et mensuel (certificats, tendances).
• Les seuils 80% CPU / 85% mémoire sont des repères opérationnels, pas les seuils réels d’éviction du kubelet. Les évictions reposent sur des signaux comme memory.available ou nodefs.available.
• Préférez le nettoyage automatique (ttlSecondsAfterFinished, revisionHistoryLimit, successfulJobsHistoryLimit) au nettoyage manuel systématique.
• Les certificats du plan de contrôle expirent après 1 an (kubeadm). Surveillez-les chaque mois et renouvelez sans supprimer les manifests.
• Un problème persistant sur un composant cœur de kube-system (DNS, CNI, kube-proxy) est toujours prioritaire. Un pod applicatif en échec peut souvent attendre.
• Cette checklist manuelle prépare la transition vers un monitoring automatisé (Prometheus, Alertmanager) sans le remplacer.

Prochaines étapes

Observer la santé du cluster Les 5 commandes de base pour évaluer l'état global d'un cluster Kubernetes

Analyser les événements Kubernetes Interpréter kubectl events pour diagnostiquer les problèmes récurrents

Méthode de diagnostic d'un incident Workflow structuré pour qualifier, isoler et corriger un incident Kubernetes

Gérer les nœuds au quotidien Labels, taints, annotations et remplacement de nœuds

×

📖 Voir la documentation →