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

Ces commandes gagnent à être réunies dans un script que vous lancez chaque matin, ou dans un tableau de bord. L'intérêt n'est pas le gain de frappe : c'est de toujours regarder les mêmes choses, y compris les jours où tout va bien, pour reconnaître ce qui sort de l'ordinaire.

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 avec les Jobs et les traitements par lots. Leur durée de conservation 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=... : ces Pods sont la matière première du diagnostic à court terme. Préférez ttlSecondsAfterFinished sur les Jobs, qui nettoie automatiquement après un délai que vous choisissez. Ne supprimez à la main un Pod Failed ou Succeeded qu'après analyse, ou dans le cadre d'une politique de rétention explicite.

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

Chaque mise à jour progressive crée un nouveau ReplicaSet. Kubernetes en conserve un historique, 10 révisions par défaut, réglées par spec.revisionHistoryLimit. Vérifiez que cette valeur reste 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, quand Used approche Hard, annonce que les prochains déploiements de ce namespace échoueront. Anticipez : augmentez le quota, ou nettoyez 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
memory.available	100Mi
nodefs.available	10%
nodefs.inodesFree	5%
imagefs.available	15%
imagefs.inodesFree	5%

Glissez pour voir

Ces cinq signaux déclenchent tous la même chose : une éviction de pods. Ne les confondez pas avec le garbage collection des images, qui est un mécanisme distinct, gouverné par deux autres réglages, imageGCHighThresholdPercent (85 % par défaut) et imageGCLowThresholdPercent (80 %). Le premier déclenche le nettoyage, le second dit quand s'arrêter. Autrement dit, le kubelet supprime des images bien avant d'en arriver à évincer des pods.

Si kubectl describe node affiche DiskPressure: True, le nœud a atteint un seuil d'éviction. Le kubelet évince alors les Pods par ordre de classe de qualité de service, les BestEffort en premier.

Le kubelet fait déjà ce ménage tout seul, dès le seuil de 85 % vu plus haut. Le nettoyage manuel avec crictl rmi --prune doit donc rester une action ciblée, décidée devant une pression disque avérée, et non une tâche récurrente : l'inscrire dans une routine revient à faire à la main, moins bien, ce que le nœud fait déjà.

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 et kube-scheduler, selon votre méthode d'exploitation. Sur un cluster kubeadm en Pods statiques, cela passe par un redémarrage contrôlé de ces Pods. Ne supprimez jamais définitivement leurs manifestes de /etc/kubernetes/manifests/ : 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 valoir True, et EXPIRATION doit être dans le futur. Un certificat à False demande une investigation : journaux du Pod cert-manager, défi DNS ou 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 hausse régulière signale un besoin de capacité : ajout de nœuds, révision des requests et limits, ou nettoyage des charges de travail inutilisées.

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

Tempérez toutefois la lecture de ce namespace : un pod en échec dans kube-system n'est pas toujours critique. Ce peut être un ancien pod de Job, un addon accessoire ou un redémarrage transitoire sans conséquence. Concentrez l'investigation sur les composants cœur, ceux dont la panne se voit partout ailleurs : CoreDNS, le CNI, kube-proxy, metrics-server et le driver de stockage.

Cette liste est un point de départ, pas une destination. Ce qu'elle vérifie à la main, une chaîne d'observabilité le surveille en continu et alerte sans que personne y pense. Tant qu'elle n'existe pas, la liste tient le rôle ; une fois qu'elle existe, gardez-en la part que les alertes ne couvrent pas.

Dépannage

Les symptômes ci-dessous se rencontrent en faisant cette routine, pas en exploitant une application. Ils ont un point commun : ils décrivent un cluster qui fonctionne mais qui accumule, et que personne ne remarque tant qu'une limite n'est pas atteinte.

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.

Contrôle de connaissances

Sept questions sur ce qu'une routine doit vraiment surveiller : la différence entre nettoyer des images et évincer des Pods, ce qu'un quota saturé annonce, et pourquoi supprimer des Pods terminés efface des preuves.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Audit Logs : La trace des actions sur l'API, à verser dans la revue périodique.
• Falco : La détection runtime qui alimente les alertes traitées au quotidien.
• Pod Security Standards : Le garde-fou à vérifier lors des revues périodiques, avant qu'un Pod privilégié ne s'installe durablement.

×

📖 Voir la documentation →