L'exploitation réactive, c'est subir les incidents. L'exploitation SRE, c'est les anticiper. La différence entre un cluster qu'on surveille et un cluster qu'on subit, c'est la structuration : des rituels d'exploitation réguliers, des runbooks documentés et des indicateurs de fiabilité mesurables.
La démarche Site Reliability Engineering, ou SRE, appliquée à Kubernetes repose sur trois piliers : une routine d'exploitation qui couvre les vérifications essentielles, des procédures d'intervention qui capitalisent sur les incidents résolus, et des objectifs de service chiffrés qui rendent la fiabilité observable.
Les trois niveaux d'exploitation structurée
Section intitulée « Les trois niveaux d'exploitation structurée »Niveau 1, La routine d'exploitation
Section intitulée « Niveau 1, La routine d'exploitation »Des rituels réguliers pour détecter les dégradations avant qu'elles deviennent des incidents :
- Quotidien : état des nœuds, pods en erreur, consommation des ressources critiques, alertes actives
- Hebdomadaire : nettoyage des ressources orphelines, révision des événements, contrôle des certificats à expiration courte, audit des images obsolètes
- Mensuel : révision des quotas, audit RBAC, rotation des secrets, test de restauration
Niveau 2, Les runbooks
Section intitulée « Niveau 2, Les runbooks »Un runbook est une procédure documentée pour un type d'incident récurrent. Il répond à : Que faire si X arrive ?
Caractéristiques d'un bon runbook :
- Déclenché par une alerte ou un symptôme précis (pas générique)
- Actions dans l'ordre, avec les commandes exactes
- Critères de succès explicites
- Escalade documentée si la procédure échoue
Niveau 3, SLO et SLI
Section intitulée « Niveau 3, SLO et SLI »Un SLI (Service Level Indicator) mesure la fiabilité d'un service : taux d'erreur, latence p99, disponibilité.
Un SLO (Service Level Objective) fixe la cible : « 99,5% des requêtes répondent en moins de 500ms sur 30 jours ».
Le budget d'erreur (100% - SLO) définit la marge d'expérimentation acceptable avant de prioriser la fiabilité sur les nouvelles fonctionnalités.
Guides de cette section
Section intitulée « Guides de cette section »À retenir
Section intitulée « À retenir »- La réactivité est coûteuse : chaque incident non anticipé coûte plus que la routine qui l'aurait prévenu
- Les runbooks réduisent le MTTR (Mean Time To Recover) en éliminant l'improvisation sous stress
- Un SLO sans budget d'erreur n'est pas actionnable, le budget d'erreur est la mécanique qui rend les SLO utiles
- Commencez simple : une vérification matinale, un runbook pour CrashLoopBackOff, un SLI de disponibilité, puis itérez
- Kubernetes fournit les primitives (events, metrics-server, readiness probes), l'exploitation les exploite
Pour aller plus loin
Section intitulée « Pour aller plus loin »- CIS Benchmark : L'audit de configuration du cluster, contrôle à inscrire dans la routine d'exploitation.
- Audit Logs : La traçabilité des actions sur l'API, matière première de tout post-mortem.
- Falco : La détection à l'exécution, qui transforme un comportement anormal en alerte exploitable par l'astreinte.