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 5 blocs : observation, diagnostic, maintenance, stabilité et exploitation structurée. 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 cinq 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 industrialise une fois les interventions maîtrisées.

• Observer : vérifier l'état du cluster, analyser les événements, lire les métriques avec Prometheus et Grafana
• 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

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 cinq blocs qui suivent le cycle réel de l'exploitation : observer, diagnostiquer, maintenir, stabiliser, industrialiser. 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.

Pour suivre l'état du cluster dans le temps plutôt qu'à l'instant, les métriques se collectent avec Prometheus et se lisent dans Grafana : Prometheus sur Kubernetes déploie la pile kube-prometheus-stack et ses ServiceMonitor, et le guide Grafana construit les dashboards et l'alerting.

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.

Quand la méthode vous mène au niveau réseau, deux guides couvrent les deux causes les plus fréquentes : Network Policies pour le filtrage entre pods, et CoreDNS pour la résolution de noms.

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. Le comportement du kubelet sous pression de nœud, avec ses seuils d'éviction, est décrit dans la routine d'exploitation.

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.

La page de synthèse du bloc détaille les trois niveaux : la routine, les runbooks pour les incidents récurrents, et la définition chiffrée des SLO et SLI par service.

Cluster unique ou plusieurs clusters ?

Cette décision d'architecture ne se prend qu'après avoir exploité un cluster unique assez longtemps pour en connaître le coût réel. Deux questions y reviennent : à partir de quels signaux un cluster devient trop complexe pour être exploité tel quel, et faut-il un cluster unique ou plusieurs, selon les critères d'isolation, de coût, de complexité et de conformité. Les cinq blocs précédents fournissent les mesures qui nourrissent l'arbitrage : fréquence des incidents, temps de maintenance, budget d'erreur consommé.

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.

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

2. Apprenez à diagnostiquer : la méthode de diagnostic vous donne une approche systématique. Appliquez-la ensuite sur les cas concrets (CrashLoopBackOff, Pending, réseau).

3. Préparez vos interventions : avant toute maintenance, suivez le guide Préparer une maintenance pour éviter les interruptions de service.

4. Stabilisez la plateforme : disponibilité applicative, PodDisruptionBudget, requests et limits, autoscaling. Ce bloc prévient les incidents au lieu de les subir.

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

Glissez pour voir

À 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

×

📖 Voir la documentation →