Opérer Kubernetes : du monitoring à la maintenance en production

Opérer Kubernetes consiste à observer l'état d'un cluster, qualifier un incident, intervenir sans casser la production, puis réduire la probabilité que l'incident se reproduise. C'est le métier qui commence une fois les manifests déployés. Ce parcours réunit 11 guides pratiques et 4 pages de synthèse, répartis en 6 blocs : observation, diagnostic, maintenance, stabilité, exploitation et décisions d'architecture. Il vise les administrateurs et les profils SRE qui gèrent un cluster déjà en service.

Chaque guide suit la même logique : comprendre le problème, appliquer une méthode, vérifier le résultat.

Ce que ce parcours couvre

Les six axes ci-dessous suivent l'ordre naturel d'une montée en maturité : on observe avant de diagnostiquer, on diagnostique avant de maintenir, et on ne décide d'une architecture multi-cluster qu'après avoir exploité un cluster unique assez longtemps pour en connaître les limites.

Observer : vérifier l'état du cluster, lire les métriques, centraliser les logs, analyser les événements, détecter les problèmes nœud
Diagnostiquer : méthode reproductible, résolution des erreurs courantes (CrashLoopBackOff, Pending, ImagePullBackOff, réseau)
Maintenir : cordon/drain, gestion des nœuds, mises à jour, sauvegardes
Stabiliser : requests/limits en production, pression des nœuds, PDB, autoscaling
Industrialiser : runbooks, SLO/SLI, tâches quotidiennes
Décider : quand un cluster devient complexe, mono vs multi-cluster

Prérequis

Ce parcours suppose un cluster déjà installé : aucun guide ne repart de zéro. Si vous n'en avez pas sous la main, un cluster k3d ou kind local suffit pour rejouer la quasi-totalité des commandes, à l'exception des manipulations de nœuds physiques.

Un cluster Kubernetes fonctionnel (v1.28+)
kubectl configuré et connecté
Connaissances de base sur les Pods, les Deployments et les Services
Avoir suivi le parcours Kubernetes fondamentaux ou équivalent

Comment le parcours est-il organisé, bloc par bloc ?

Les 15 pages du parcours se répartissent en six blocs qui suivent le cycle réel de l'exploitation : observer, diagnostiquer, maintenir, stabiliser, industrialiser, décider. Si vous débutez en exploitation Kubernetes, commencez par le bloc « Observer » : savoir lire l'état d'un cluster conditionne tout le reste, y compris la capacité à juger si un symptôme mérite une intervention.

Observer et superviser le cluster

Le premier bloc rend l'état du cluster visible et interprétable avant l'incident. Un cluster qu'on ne regarde qu'en situation de panne ne fournit aucun point de comparaison : sans référence, impossible de savoir si les redémarrages observés ce matin sont anormaux ou constituent le régime habituel de la plateforme.

Observer la santé d'un cluster en 5 commandes : nœuds, conditions, metrics-server, consommation CPU et mémoire, événements.
Analyser les événements Kubernetes : lire, filtrer et exploiter les objets Event pour repérer une dérive avant qu'elle ne déclenche une alerte.

Trois sujets de ce bloc restent à écrire : la mise en place des métriques avec Prometheus et Grafana, la centralisation des logs des pods et du plan de contrôle, et la surveillance matérielle des nœuds avec Node Problem Detector.

Diagnostiquer les incidents applicatifs

Le deuxième bloc fournit une méthode par type d'incident : qualifier, isoler, confirmer, corriger. On commence toujours par qualifier le symptôme au niveau cluster, puis nœud, puis pod, puis réseau. Cette descente du plus global au plus local évite de passer une heure sur une hypothèse applicative alors que le nœud est en pression mémoire.

Diagnostiquer les incidents applicatifs : la page de synthèse du bloc, avec les trois commandes qui donnent le contexte initial.
Méthode de diagnostic d'un incident Kubernetes : l'approche systématique en 4 niveaux, cluster, nœud, pod, réseau.
Diagnostiquer un CrashLoopBackOff : le backoff exponentiel, ses 6 causes fréquentes et la méthode en 4 étapes.
Diagnostiquer un Pod Pending : ressources insuffisantes, taints, affinité, PersistentVolumeClaim non lié.
Diagnostiquer un ImagePullBackOff : registre inaccessible, tag introuvable, imagePullSecret manquant.

Le diagnostic purement réseau, du DNS aux EndpointSlice en passant par les Network Policies, n'a pas encore son guide dédié dans ce bloc. En attendant, Network Policies et CoreDNS couvrent les deux causes les plus fréquentes.

Maintenir le cluster sans coupure

Le troisième bloc traite les interventions planifiées. Chaque opération de maintenance est une disruption volontaire : cordon, drain, montée de version, remplacement de nœud. Les PodDisruptionBudget sont ce qui empêche un kubectl drain de vider en une fois toutes les répliques d'un service, et c'est la raison pour laquelle ils se posent avant la première maintenance, pas après le premier incident.

Maintenance et changements : la page de synthèse du bloc.
Préparer une maintenance de cluster : cordon, drain, uncordon, PodDisruptionBudget, le workflow complet avant intervention.
Gérer les nœuds d'un cluster : labels, taints, annotations, remplacement d'un nœud défaillant.
Mettre à jour un cluster : version skew policy, ordre des composants, workflow kubeadm upgrade et vérifications après montée de version.

La sauvegarde du cluster n'a pas de guide propre à ce parcours, mais le sujet est traité dans Sauvegarder et restaurer Kubernetes, qui couvre le snapshot etcd et la sauvegarde des ressources.

Stabiliser et dimensionner la plateforme

Le quatrième bloc fait passer du dépannage à la prévention. La différence tient à un point de méthode : le dépannage traite un symptôme observé, la stabilisation traite une cause structurelle, presque toujours un dimensionnement approximatif ou une absence de contrainte de disponibilité.

Fiabiliser les applications Kubernetes : la page de synthèse du bloc.
Disponibilité applicative : PodDisruptionBudget, anti-affinité, probes, garantir la continuité pendant les opérations.

Deux sujets connexes sont déjà couverts hors de ce parcours : Requests et Limits pour le dimensionnement des conteneurs, et l'autoscaling pour le HPA, le VPA et le Cluster Autoscaler. Restent à écrire l'angle production des requests et limits, et le comportement du kubelet sous pression de nœud, avec ses seuils d'éviction.

Industrialiser l'exploitation

Le cinquième bloc remplace l'administration au fil de l'eau par des rituels, des indicateurs et des procédures écrites. C'est le bloc qui change le plus la vie d'une équipe d'astreinte : un incident traité par un runbook se règle de la même façon quelle que soit la personne de garde, ce qui n'est jamais le cas d'un incident traité de mémoire.

SRE et exploitation Kubernetes : la page de synthèse du bloc, SLO, SLI et budget d'erreur.
Routine d'exploitation Kubernetes : vérifications matinales, nettoyage hebdomadaire, contrôle mensuel des certificats et des quotas.

Restent à écrire dans ce bloc : la rédaction des runbooks pour les incidents récurrents, et la définition chiffrée des SLO et SLI par service.

Décider de l'architecture

Le sixième bloc ne traite pas d'opérations mais d'arbitrages. Deux questions y reviennent en permanence : à partir de quels signaux un cluster est-il devenu trop complexe pour être exploité tel quel, et faut-il un cluster unique ou plusieurs clusters selon les critères d'isolation, de coût, de complexité et de conformité. Ces deux guides ne sont pas encore écrits ; l'arbitrage ne se pose utilement qu'après les cinq blocs précédents, parce qu'il demande de connaître le coût réel d'exploitation d'un cluster.

Dans quel ordre suivre ces guides ?

Suivez les blocs dans l'ordre, en commençant par l'observation et en terminant par l'industrialisation. Cet enchaînement n'est pas une préférence pédagogique : chaque étape produit ce dont la suivante a besoin. Sans référence d'observation, un diagnostic n'a rien à comparer ; sans méthode de diagnostic, une maintenance se prépare à l'aveugle ; sans maintenance maîtrisée, les indicateurs de fiabilité mesurent surtout vos propres interventions.

Commencez par observer : le guide Observer la santé du cluster vous donne les 5 commandes essentielles pour vérifier l'état de votre cluster. C'est le point de départ de toute exploitation.
Apprenez à diagnostiquer : la méthode de diagnostic vous donne une approche systématique. Appliquez-la ensuite sur les cas concrets (CrashLoopBackOff, Pending, réseau).
Préparez vos interventions : avant toute maintenance, suivez le guide Préparer une maintenance pour éviter les interruptions de service.
Stabilisez la plateforme : disponibilité applicative, PodDisruptionBudget, requests et limits, autoscaling. Ce bloc prévient les incidents au lieu de les subir.
Structurez l'exploitation : la routine d'exploitation, les runbooks et les SLO transforment l'administration ponctuelle en exploitation reproductible.

Quels autres parcours Kubernetes compléter ?

Ce parcours ne traite que l'exploitation d'un cluster déjà en service. Les guides ci-dessous couvrent l'installation, la conception et la préparation à la certification CKA, et se lisent en parallèle. La colonne « Type de lien » indique ce que vous y trouverez de plus : un complément ajoute un sujet voisin, un approfondissement creuse le même sujet plus loin.

Guide « Opérer »	Parcours lié	Type de lien
Observer la santé du cluster	Troubleshooting CKA	Complémentaire
Diagnostiquer un CrashLoopBackOff	Troubleshooting CKA	Approfondissement
Préparer une maintenance	kubeadm, Worker Nodes	Complémentaire
Disponibilité applicative	Requests et Limits	Angle production
Diagnostiquer les incidents applicatifs	Network Policies, CoreDNS	Complémentaire

À retenir

Cinq principes résument l'ensemble du parcours. Ils tiennent en une phrase chacun parce qu'ils servent de repère pendant un incident, moment où personne ne relit un guide de quinze pages.

Observer avant d'agir : la majorité des incidents sont détectables avec 5 commandes kubectl avant qu'ils ne deviennent critiques
Une méthode reproductible vaut mieux que 10 astuces isolées, qualifier, isoler, confirmer, corriger
Chaque maintenance doit être préparée : cordon, drain, vérification des PDB, puis uncordon
La fiabilité se construit : requests/limits correctes, PDB en place, autoscaling configuré
L'exploitation structurée (runbooks, SLO/SLI, routine) réduit le stress et le temps de résolution

Pour aller plus loin

Méthode de diagnostic : La démarche ordonnée à suivre dès qu'une alerte tombe sur le cluster.
Diagnostiquer un CrashLoopBackOff : L'incident applicatif le plus fréquent, traité de bout en bout.
Maintenance et changements : Le volet planifié de l'exploitation, des drains aux montées de version.
SRE et exploitation Kubernetes : Les SLO et le budget d'erreur qui donnent une règle de décision aux astreintes.