SLO Kubernetes SRE : définir, mesurer, piloter

Publié le

14 juil. 2026

Temps de lecture

11 min de lecture

Kubernetes permet de mesurer facilement les pods, les nœuds et les requêtes API. Ces signaux sont essentiels, mais ils ne constituent pas un objectif de niveau de service (SLO). Un SLO est une cible convenue pour un résultat visible par l'utilisateur sur une période définie, associée à un indicateur de niveau de service (SLI) qui montre si cette cible est atteinte.

Pour les équipes DevOps, la valeur pratique réside dans la prise de décision. Un service qui a consommé l'essentiel de son budget d'erreur doit recevoir des travaux de fiabilité avant une mise en production risquée. Une régression de latence isolée à une région ou à un endpoint doit être examinée à la couche concernée, et non masquée par une moyenne dans un tableau de bord à l'échelle du cluster.

Commencer par les parcours utilisateurs critiques

Cartographiez les parcours qui donnent sa valeur au service : connexion, recherche, paiement, écriture API, soumission d'une tâche en arrière-plan ou action administrative. Pour chacun, identifiez la limite du service et la réponse reçue par le client. Un Deployment ou un namespace Kubernetes constitue souvent une limite d'implémentation, et non la bonne limite pour le SLO.

Choisissez un premier ensemble restreint. Un bon point de départ est un SLI de disponibilité et un SLI de latence pour un chemin de requête critique, auxquels s'ajoute un SLI de fraîcheur ou de complétion lorsque le travail asynchrone compte. Documentez explicitement les exclusions, telles que le comportement de maintenance, les requêtes annulées par le client ou les endpoints qui ne font pas partie du parcours. Les exclusions doivent être observables et révisées ; elles ne doivent pas servir à supprimer les échecs gênants.

Définir les indicateurs avant les cibles

Un indicateur de disponibilité divise généralement les requêtes valides par les requêtes réussies. Définissez précisément ces deux termes. Décidez par exemple quels codes de statut comptent comme un succès, si les requêtes limitées en débit signalent un service surchargé ou une politique intentionnelle, et comment traiter les requêtes qui n'atteignent jamais l'application.

Un indicateur de latence doit mesurer la durée perçue par l'utilisateur ou l'appelant. Pour les services HTTP, enregistrez un histogramme à l'entrée ou à la limite de l'application et étiquetez-le avec un modèle de route stable, une classe de réponse, une région et une version de déploiement lorsque la cardinalité reste maîtrisée. Les percentiles et les ratios d'événements conformes à un seuil répondent à des questions différentes. Un SLI fondé sur un seuil peut exprimer directement : « quelle proportion des requêtes valides s'est terminée dans la durée choisie ? »

Évitez de dériver un SLI de latence visible par l'utilisateur uniquement à partir du CPU, du nombre de redémarrages de pods ou des métriques kubelet. Ce sont des signaux de diagnostic. Associez les mesures de requêtes aux traces et à la télémétrie d'infrastructure afin qu'une violation de SLO puisse être reliée à une saturation, une dépendance amont, un déploiement d'image, un comportement DNS ou une modification du chemin de livraison.

Choisir soigneusement les cibles et les budgets d'erreur

Définissez la cible initiale à partir des attentes des clients, des engagements contractuels le cas échéant, des limites des dépendances et des performances observées. Une cible plus stricte n'est pas automatiquement préférable : elle peut mobiliser de la capacité d'ingénierie sur des variations que les utilisateurs ne remarquent pas tout en masquant un parcours plus important. Réexaminez les cibles après plusieurs cycles d'exploitation significatifs, et non après une seule semaine calme.

Le budget d'erreur est le volume autorisé de mauvais événements déduit du SLO sur sa période. Définissez si le budget est calculé à partir des requêtes, du temps, des tâches ou d'une autre population d'événements. Les services à faible volume exigent un traitement particulier, car une poignée d'échecs peut produire des pourcentages instables ; utilisez des règles de trafic minimal, des périodes plus longues ou un signal opérationnel distinct au lieu de prétendre que la mesure est statistiquement stable.

Utilisez à la fois une longue période de conformité et des périodes plus courtes de burn rate. La longue période indique si l'objectif est atteint. Les périodes courtes et intermédiaires identifient un budget consommé assez rapidement pour exiger une réponse. Les alertes doivent combiner le burn rate avec l'impact et le volume de trafic afin qu'un unique contrôle de santé en échec ne réveille pas une équipe, alors qu'un préjudice durable pour les clients le fasse.

Instrumenter le chemin de requête Kubernetes

Construisez un chemin de mesure qui résiste aux changements de placement et de nombre de réplicas des pods :

• Émettez depuis le service ou l'ingress des métriques de durée de requête, de statut et de route avec des labels bornés.
• Propagez le contexte de trace W3C depuis la périphérie ou l'équilibreur de charge via l'ingress, le service mesh s'il est présent, l'application, la file d'attente et les appels en aval.
• Exportez la télémétrie des ressources et des événements Kubernetes pour expliquer les retards de planification, redémarrages, limitations, évictions et l'état des déploiements.
• Synchronisez les horloges et associez systématiquement le nom du service, l'environnement, la région et la version de publication aux métriques, journaux et traces.
• Testez la télémétrie sous charge ; un chemin de métriques qui ajoute trop de labels ou perd des histogrammes au pic de trafic ne peut pas prendre en charge un SLO opérationnel.

OpenTelemetry est utile pour standardiser la télémétrie applicative, tandis que les métriques Kubernetes restent précieuses pour le diagnostic de la plateforme. Ni l'un ni l'autre ne remplace l'autre. Clarifiez les responsabilités : les équipes applicatives sont responsables du comportement qu'elles exposent, et les équipes plateforme du plan de contrôle partagé, des nœuds, du réseau et des capacités d'observabilité qui l'affectent.

Relier les SLO aux processus de mise en production et d'incident

Créez une réponse écrite pour chaque état du budget. Par exemple, une consommation normale du budget peut autoriser les mises en production habituelles ; un burn rate élevé peut exiger une revue de mise en production, des diagnostics supplémentaires ou une pause des changements sur le service affecté ; l'épuisement peut déclencher des travaux de fiabilité ou une décision explicite de la direction d'accepter le risque. Ce sont des politiques, pas des lois automatiques. Un correctif de sécurité ou une correction client urgente peut toujours justifier une mise en production lorsque son risque est compris.

Lors d'un incident, utilisez le SLI pour établir l'impact client et le périmètre. Examinez ensuite les signaux d'appui : erreurs d'ingress, disponibilité des pods, profondeur de file d'attente, latence de base de données, réponses DNS, état amont et mesures de livraison régionales. Enregistrez les versions de configuration et de publication dans la chronologie. Un tableau de bord vert des nœuds ne prouve pas qu'un parcours client a été rétabli.

Inclure le chemin de livraison dans la responsabilité de la latence

Pour les services publics, mesurez séparément dans le navigateur ou le client, à la périphérie, dans l'ingress, dans l'application et au niveau de chaque dépendance critique. Cela évite qu'une équipe d'origine considère tout délai comme un problème applicatif, ou qu'une équipe de livraison considère un ralentissement de l'origine comme un problème de périphérie. Segmentez par région, réseau, route et état du cache lorsque ces dimensions sont disponibles et affectent sensiblement l'expérience.

Ne supposez pas qu'un point de présence plus proche, un CDN ou une région supplémentaire améliore chaque requête. Les chemins dynamiques, authentifiés et riches en écritures peuvent encore dépendre d'un magasin de données distant ou d'un service d'identité centralisé. Testez le parcours complet et préservez la correction, le comportement de session, la confidentialité et les exigences d'invalidation avant de modifier la politique de trafic.

Liste de contrôle

Avant de vous appuyer sur un SLO, vérifiez que le parcours et la limite de mesure sont documentés ; que les labels sont bornés ; que les règles des mauvais événements sont convenues ; que les cibles ont un responsable ; que la politique de budget d'erreur est actionnable ; que les alertes de burn rate sont testées ; que les tableaux de bord renvoient aux traces et aux journaux ; et que les échecs de dépendance ou du chemin de livraison peuvent être distingués des échecs applicatifs.

Références officielles

• Google SRE: Service Level Objectives
• Google SRE: Alerting on SLOs
• Kubernetes: Metrics for Kubernetes System Components
• OpenTelemetry Documentation