SLO Kubernetes SRE : définir, mesurer, piloter

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

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

À l'échelle où opère une couche d'orchestration d'edge managée — de nombreux services et fournisseurs devant une même origine — un tableau de bord de cluster entièrement vert cesse d'être un indicateur fiable de l'expérience client bien avant que quiconque ne s'en aperçoive depuis l'intérieur du cluster. Les SLO Kubernetes et leurs budgets d'erreur sont précisément ce qui permet à une équipe plateforme de convenir du moment où une mise en production est sans risque.

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.

Cas pratique : le paiement d'Acme Shop

Acme Shop exploite checkout-api derrière un ingress. Une requête de paiement valide est une requête qui atteint la route et reçoit une réponse 2xx, 3xx ou 5xx ; les requêtes 4xx, malformées ou intentionnellement rejetées, sont suivies séparément et ne sont jamais reclassées après coup pour arranger un incident. Un bon événement valide est une réponse 2xx ou 3xx. Le premier objectif est une disponibilité de 99,9 % sur une fenêtre glissante de 30 jours. Le second porte sur la latence des requêtes réussies : 95 % des bonnes requêtes de paiement doivent se terminer en moins de 300 ms, et 99 % en moins de 900 ms, les deux mesures étant prises au niveau de l'ingress plutôt qu'à l'intérieur de l'application.

Le chemin de mesure suit l'ensemble du parcours : la périphérie ajoute le contexte de trace et enregistre le résultat de livraison, l'ingress restitue le statut et la durée au niveau de la route, checkout-api relie le résultat aux preuves de version et de dépendance, des règles d'enregistrement Prometheus calculent les événements valides, les bons événements, la latence et les taux de consommation du budget sur plusieurs fenêtres, et le tableau de bord — combiné aux alertes de burn rate et à la porte de mise en production — pilote une réponse ciblée plutôt qu'un contrôle de santé isolé.

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 des SLO Kubernetes : indicateurs et budgets d'erreur

Un bon SLO Kubernetes part d'un ratio que toute l'équipe peut auditer, pas du percentile qu'un tableau de bord affiche par défaut. Pour la disponibilité, retenez le bon sens du ratio :

disponibilité = bons événements valides / total des événements valides

Sur 1 000 000 de requêtes de paiement valides pour une cible de 99,9 %, Acme Shop dispose d'un budget de 1 000 événements mauvais sur la fenêtre de 30 jours. Si 250 requêtes sont mauvaises, la disponibilité est de 999 750 / 1 000 000 = 99,975 % et 250 / 1 000 = 25 % du budget d'erreur est consommé. Un taux d'événements mauvais de 1 % représente dix fois le taux autorisé de 0,1 %, soit un burn rate de 10x. Ce calcul n'a de sens que si la définition d'un événement valide reste stable, que les deux termes du ratio sont précisément arbitrés — quels codes de statut comptent comme un succès, comment traiter les requêtes limitées en débit ou celles qui n'atteignent jamais l'application — et que le trafic est suffisant pour l'interpréter.

Pour la latence, préférez plusieurs seuils de percentile à une moyenne unique : une moyenne masque la traîne lente à l'origine des réclamations, et un percentile élevé isolé peut sembler correct alors que les requêtes ordinaires se dégradent discrètement. Acme Shop considère une requête comme bonne pour l'objectif strict en dessous de 300 ms, et suit séparément une borne plus large de 900 ms au 99e percentile, afin qu'une régression limitée à la traîne apparaisse avant d'atteindre le 95e percentile. Le CPU, le nombre de redémarrages et l'état de préparation des pods restent des signaux de diagnostic, jamais des substituts à l'un ou l'autre indicateur ; associez toujours 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.

Une fenêtre glissante de 30 jours dilue progressivement les incidents anciens et convient aux décisions de mise en production ; une fenêtre calendaire trimestrielle se rapporte plus clairement à la direction. Acme Shop utilise les deux, alimentées par les mêmes règles d'enregistrement.

Budgets d'erreur : cibles et fenêtres de burn rate

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.

Découpez les règles d'enregistrement Prometheus (ou l'équivalent chez votre fournisseur de métriques) de façon à limiter chaque fenêtre — 5 minutes, 1 heure, 6 heures, 3 jours — à une seule règle, afin que les expressions d'alerte restent courtes et faciles à relire. Réutilisez le même histogramme de durée pour les deux seuils de latence, par exemple 300 ms et 900 ms, plutôt que de dupliquer l'instrumentation par seuil.

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.

Alerting SRE : règles multi-fenêtres et multi-burn-rate

Une unique condition de burn rate rapide sur une seule fenêtre courte ne suffit pas pour un alerting SRE en production : un pic bref peut franchir un seuil de burn rate élevé sans menacer le budget, tandis qu'une fuite lente peut rester sous un seuil de fenêtre courte tout en consommant l'essentiel du budget. Le workbook SRE de Google corrige ce défaut en exigeant l'accord de deux fenêtres : une longue qui prouve que la consommation est réelle, une courte qui prouve qu'elle est toujours en cours.

Acme Shop retient trois paliers d'alerting SRE. La « page rapide » (1h/5m, burn rate 14,4x, ~2 % du budget par heure) déclenche un appel immédiat, traité comme un incident actif. La « page lente » (6h/30m, burn rate 6x, ~5 % sur six heures) déclenche aussi un appel, mais laisse le temps de diagnostiquer avant que la tendance ne s'aggrave. Le « ticket » (3j/6h, burn rate 1x, ~10 % sur trois jours) ouvre un ticket à résoudre avant la prochaine mise en production planifiée, sans réveiller personne.

Parce qu'une alerte ne reste active que tant que les deux fenêtres sont mauvaises, elle se résorbe en quelques minutes après une reprise réelle, plutôt que de rester allumée pendant le reste de la fenêtre longue. Associez systématiquement chaque condition de burn rate à un garde-fou de volume minimal de requêtes valides, sinon une route à faible trafic peut franchir un seuil sur une poignée de requêtes sans aucun poids statistique ; une route nouvellement lancée doit par exemple totaliser au moins 1 000 requêtes valides sur sa fenêtre la plus courte avant de pouvoir déclencher un appel, et retombe sur un ticket tant que le trafic n'atteint pas ce plancher. La même logique à deux fenêtres s'applique au SLI de latence : le paiement peut être parfaitement disponible tout en échouant son objectif de latence.

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

Créez une réponse écrite pour chaque état du budget. La politique d'Acme Shop illustre ce principe : sous 50 % de budget consommé, les mises en production suivent la revue normale ; entre 50 % et 90 %, une mise en production exige un second relecteur et un plan de retour arrière ; au-delà de 90 %, seuls les correctifs de fiabilité et les correctifs de sécurité pré-approuvés sont déployés, jusqu'à la réinitialisation du budget ou une décision explicite des responsables d'accepter le risque. La politique nomme des rôles, pas des personnes, et vit à côté du runbook plutôt que dans une mémoire partagée invoquée en plein incident. Un correctif de sécurité urgent 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, et un panneau de disponibilité vert ne prouve pas que la latence l'est aussi : passez en revue les deux SLI, ainsi que les SLO de dépendance que le parcours compose, avant de clore un incident.

Avant de faire confiance à ces règles en production, validez-les dans un environnement non productif : envoyez un nombre connu de requêtes de paiement synthétiques produisant à la fois des réponses 2xx et des 5xx contrôlées, plus un lot avec un délai injecté au-delà de 300 ms et 900 ms, puis vérifiez que les règles d'enregistrement des événements valides, bons et de latence correspondent aux comptages attendus et inspectez une trace par cohorte. Provoquez ensuite une panne courte qui se résorbe en quelques minutes pour confirmer que l'alerte de burn rate rapide s'éteint dès que la fenêtre courte redevient saine, et non simplement dès qu'elle figure dans le fichier de règles. Si une règle étiquette incorrectement du trafic valide, retirez uniquement la règle non approuvée ou restaurez sa dernière révision relue, sans modifier la gestion des statuts ni supprimer une alerte de façon globale. Si le pipeline de métriques est indisponible ou le volume trop faible, déclarez la mesure du SLO indisponible avant de vous y appuyer pour une décision de mise en production.

Diagnostiquer les signaux SLO trompeurs

Certains symptômes reviennent assez souvent pour mériter un diagnostic type plutôt qu'une improvisation en plein incident.

• La disponibilité affiche plus de 100 % ou reste absente. Les requêtes « bonnes » et « valides » utilisent probablement des filtres d'étiquettes différents, ou le dénominateur est nul : interrogez les deux règles avec le même périmètre de route et de service, corrigez la règle relue, puis attendez de nouveaux échantillons sans plafonner artificiellement le résultat.
• Le budget chute après une évolution de la validation côté client. Des réponses 4xx sont probablement entrées dans la population valide sans que cela soit voulu : comparez les comptages par classe de statut entre versions de déploiement, restaurez le comportement antérieur, puis documentez si le contrat du SLI doit réellement changer.
• Une alerte de burn rate rapide se déclenche sur un trafic minuscule. Le garde-fou de volume minimal est absent ou fondé sur une estimation : recalibrez le plancher à partir du trafic réel et renvoyez les routes à faible volume vers un ticket jusqu'à ce que le trafic justifie un appel.
• Le SLO est vert mais les clients signalent des ralentissements. La disponibilité est saine alors que le SLI de latence est absent, trop large, ou ne mesure qu'un seul percentile : comparez l'histogramme de durée et les cohortes de traces sur les deux seuils, puis corrigez le SLI de latence sans jamais redéfinir la disponibilité pour masquer le problème.
• Le tableau de bord ne permet pas d'identifier la région affectée. Les étiquettes de région ou de version sont absentes de la télémétrie corrélée : restaurez le contrat de télémétrie sur une trace, un journal et une série de métriques assainis, puis rejouez la validation contrôlée.

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 et nomme des rôles ; que les alertes de burn rate multi-fenêtres sont testées avec un garde-fou de volume minimal ; 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
• Prometheus Operator: API Reference
• OpenTelemetry Documentation