Le blog de Joseph Delassalle — platform engineering & SRE

Instrumenter une app Prometheus : golden signals

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=fr justification : cible les requêtes FR "instrumenter prometheus", "golden signals", "histogramme prometheus latence", "histogram_quantile", et sert de relais LinkedIn francophone. Le pendant EN vise la longue traîne mondiale (même translationKey). Article socle sous l'article alerting déjà publié : il donne les métriques que les alertes par symptôme consomment.

Note contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre le comportement documenté de Prometheus (types de métriques, histogram_quantile, format d'exposition). Aucune anecdote de production par construction ; ce n'est pas un REX. -->

Votre cluster est couvert de métriques. node_exporter remonte le CPU, la RAM et le remplissage des disques, kube-state-metrics connaît l'état de chaque pod. Puis un responsable produit demande : « le paiement est-il plus lent que ce matin ? », et personne ne sait répondre. Toutes ces métriques décrivent les machines et l'orchestrateur ; aucune ne décrit ce que fait votre application. C'est exactement le trou que l'instrumentation comble : exposer, depuis le code, les quelques chiffres qui disent si le service rend le service.

Les quatre signaux, et par où commencer

La grille la plus utile reste celle des golden signals du livre SRE de Google : la latence (combien de temps une requête prend), le trafic (combien vous en recevez), les erreurs (combien échouent) et la saturation (à quel point vos ressources sont sollicitées). La saturation est déjà largement couverte par node_exporter et les métriques du cluster. Restent trois choses à instrumenter dans l'application elle-même, ce que la méthode RED résume bien pour un service qui répond à des requêtes : Rate, Errors, Duration.

Autrement dit, avant d'ajouter la moindre métrique métier, exposez combien de requêtes arrivent, combien tournent mal, et combien de temps elles durent. Tout le reste sert au diagnostic une fois qu'un de ces trois signaux vous a alerté.

Le bon type de métrique pour la bonne question

Prometheus a quatre types de métriques, et le choix n'est pas cosmétique. Un counter ne fait que monter et se lit avec rate() : c'est le type du trafic et des erreurs, un http_requests_total porteur d'un label status. Une gauge est une valeur instantanée qui monte et descend, pour ce qui se compte à un instant donné (connexions en cours, profondeur d'une file). Un histogram échantillonne une distribution dans des tranches prédéfinies, et c'est le bon outil pour la latence. Le summary ressemble à l'histogramme mais calcule ses quantiles autrement, avec une conséquence lourde qu'on verra plus bas.

Un handler instrumenté, et les requêtes qui vont avec

Concrètement, votre bibliothèque cliente expose au scrape un format texte de ce genre :

# TYPE http_requests_total counter
http_requests_total{service="checkout",status="200"} 128934
http_requests_total{service="checkout",status="500"} 271

# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{service="checkout",le="0.1"} 24054
http_request_duration_seconds_bucket{service="checkout",le="0.3"} 33444
http_request_duration_seconds_bucket{service="checkout",le="1"}   34101
http_request_duration_seconds_bucket{service="checkout",le="+Inf"} 34115
http_request_duration_seconds_sum{service="checkout"}   5342.7
http_request_duration_seconds_count{service="checkout"} 34115

L'histogramme expose des compteurs cumulatifs par borne le (less than or equal), plus un _sum et un _count. À partir de là, deux requêtes couvrent l'essentiel :

# taux d'erreur par service
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  /
sum(rate(http_requests_total[5m])) by (service)

# latence p99 par service
histogram_quantile(
  0.99,
  sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
)

Ce sont précisément les métriques que consomment les alertes Prometheus par symptôme : instrumenter d'abord, alerter ensuite. Une règle qui surveille le taux d'erreur ou la latence n'existe que parce que l'application a été instrumentée pour les exposer.

Histogramme ou summary : pourquoi le quantile se calcule côté serveur

Voici la distinction qui décide du type à choisir. Un summary calcule ses quantiles dans le client, par instance, et publie directement un quantile="0.99". Le problème : on ne peut ni additionner ni moyenner des quantiles. Le p99 de dix pods n'est pas la moyenne de leurs dix p99. Dès que votre service tourne en plusieurs réplicas, un summary vous donne dix chiffres impossibles à recombiner en une latence de service.

L'histogramme fait l'inverse : il expose des comptes bruts par tranche, et histogram_quantile() reconstitue le quantile côté serveur, après que vous avez agrégé les buckets avec sum by (le). Comme tout tourne en plusieurs exemplaires sur Kubernetes, l'histogramme est le choix par défaut. Son coût : il faut choisir les tranches à l'avance.

Les buckets, l'interpolation, et les pièges

histogram_quantile() interpole linéairement à l'intérieur de la tranche où tombe le quantile. La précision de votre p99 est donc la largeur du bucket qui l'entoure. Les tranches par défaut (de quelques millisecondes à dix secondes) encadrent rarement un objectif réel : placez les bornes là où vous prenez des décisions. Si votre cible est 300 ms, vous voulez des bornes vers 0.25, 0.3, 0.5. Et si le quantile tombe dans la tranche +Inf, le résultat n'est plus une valeur mais une borne inférieure, signe que vos buckets sont trop grossiers. Les histogrammes natifs, plus récents, suppriment ce choix de bornes au prix d'un statut encore expérimental.

Trois autres pièges reviennent. La cardinalité d'abord : un label par utilisateur, par URL brute ou par identifiant de requête multiplie les séries par le nombre de buckets et fait exploser le coût de stockage, un sujet que détaille l'entrée de glossaire sur la cardinalité des métriques. Gardez des labels bornés : le gabarit de route, pas le chemin brut ; la classe de statut, pas le message complet. Moyenner des quantiles ensuite, avg d'un p99, qui ne veut rien dire : on agrège les buckets, jamais les quantiles. Trop peu de tranches autour de l'objectif enfin, qui rend le p99 illisible au moment précis où il compte.

À retenir

Instrumentez trois choses depuis le code, trafic, erreurs et durée, et laissez la saturation à node_exporter. Un counter pour les taux, un histogramme pour la latence, avec ses bornes posées autour de la décision que vous prenez vraiment. Préférez l'histogramme au summary dès que le service tourne en plusieurs réplicas, et tenez la cardinalité des labels, parce qu'une application instrumentée qui coûte plus qu'elle n'observe est un incident comme un autre. Cette observabilité utile est le socle de mon offre fiabilité et observabilité ; d'autres sujets dans la catégorie observabilité.

PodDisruptionBudget : contre quoi il protège vraiment

Fri, 24 Jul 2026 00:00:00 GMT

<!-- justification lang=fr : version française de l'article EN "kubernetes-pod-disruption-budget". Contenu de référence générique, sert le public francophone (relais LinkedIn FR) et le maillage vers le glossaire français. Paire liée via translationKey.

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre la documentation Kubernetes et le comportement des contrôleurs. Aucune anecdote de production par construction, ce n'est pas un REX. -->

Deux symptômes mènent à la documentation du PodDisruptionBudget, et ils pointent dans des directions opposées. Le premier : kubectl drain node-7 reste bloqué sur « evicting pod ... » sans jamais rendre la main, l'autoscaler de cluster n'arrive plus à réduire la voilure, une mise à jour de node pool cale une heure sur un seul nœud. Le second : une équipe ajoute un PDB en pensant garder son application en vie quand un nœud tombe, perd quand même la moitié de ses réplicas sur une panne matérielle, et se demande pourquoi le budget n'a rien fait. Les deux viennent de la même confusion sur ce à quoi sert réellement un PDB.

Perturbations volontaires et involontaires

Kubernetes range les perturbations de pods en deux familles, et un PDB n'en touche qu'une seule.

Les perturbations volontaires passent par l'API d'éviction : kubectl drain, l'autoscaler qui retire un nœud sous-utilisé, une mise à jour progressive d'un node pool managé, ou tout appel à POST .../pods/<nom>/eviction. Ce sont des actions délibérées, déclenchées par un opérateur ou un contrôleur.

Les perturbations involontaires sont tout le reste : un kernel panic, une panne matérielle, le nœud qui manque de mémoire et le OOM killer qui emporte votre pod, une partition réseau, une préemption au profit d'un pod plus prioritaire. Un cas surprend souvent : kubectl delete pod est une suppression directe, pas une éviction, donc le PDB ne le voit pas non plus.

Un PodDisruptionBudget est un garde-barrière devant l'API d'éviction, rien de plus. Il ne ressuscite pas un pod parti avec son nœud et ne planifie jamais de remplaçant. Si votre crainte porte sur les crashs de nœud, les leviers sont le nombre de réplicas, les topologySpreadConstraints et l'anti-affinité, pas un PDB. Ce qu'un budget vous achète, c'est une protection contre votre propre outillage qui retirerait trop de pods d'un coup pendant une opération planifiée. Il plafonne les évictions volontaires simultanées pour qu'un drain ou une réduction d'échelle ne vous fasse pas passer sous un plancher que vous fixez.

minAvailable contre maxUnavailable

Un PDB porte exactement l'un de ces deux champs, jamais les deux.

minAvailable : le nombre (ou pourcentage) de pods qui doivent rester sains. Une éviction est refusée si elle ferait passer le compte sous ce plancher.
maxUnavailable : le nombre (ou pourcentage) de pods autorisés à être indisponibles simultanément. Une éviction est refusée dès que ce seuil est atteint.

Le contrôleur de perturbation ramène l'un ou l'autre à une seule valeur calculée. Il lit le nombre de pods attendus auprès du contrôleur propriétaire (le spec.replicas d'un Deployment, par exemple), compte combien de pods sont actuellement sains (au sens Ready, ce qui explique pourquoi votre readiness probe alimente directement ce calcul), puis en déduit disruptionsAllowed = sainsActuels − sainsSouhaités. Avec minAvailable: 4, sainsSouhaités vaut 4. Avec maxUnavailable: 1 sur 6 réplicas, il vaut 5. Quand disruptionsAllowed tombe à 0, l'API d'éviction renvoie un HTTP 429 et kubectl drain patiente puis réessaie jusqu'à ce que le budget se rouvre.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
spec:
  minAvailable: 4          # ne jamais descendre sous 4 pods Ready
  selector:
    matchLabels:
      app: api
  # unhealthyPodEvictionPolicy: AlwaysAllow   # voir les pièges

$ kubectl get pdb api
NAME   MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
api    4               N/A               2                     3d

ALLOWED DISRUPTIONS: 2 signifie que deux pods peuvent être évincés à l'instant présent ; drainez un nœud qui porte trois pods api et la troisième éviction attendra.

Privilégiez maxUnavailable quand vous passez à l'échelle horizontalement : il reste correct quand replicas varie, là où un minAvailable fixe devient silencieusement plus strict à mesure que vous réduisez, et plus laxiste à mesure que vous montez.

Interaction avec les drains et l'autoscaler

kubectl drain cordonne le nœud, puis évince ses pods un par un via l'API d'éviction, en respectant chaque PDB concerné. Si un budget est épuisé, le drain n'échoue pas : il boucle, attendant que les pods soient replanifiés ailleurs et repassent Ready pour que le budget se rouvre. Un drain qui « bloque » est presque toujours un PDB qui fait son travail pendant que les remplaçants ne montent pas (pas de place pour planifier, ou un rollout coincé).

L'autoscaler de cluster s'appuie sur la même API pour réduire la voilure. Avant de retirer un nœud sous-utilisé, il vérifie que tous ses pods peuvent être évincés sans violer un PDB. Sinon, le nœud est marqué non supprimable et reste en place. Un PDB qui n'autorise jamais aucune perturbation cloue donc des nœuds au sol et sabote la consolidation, ce qui se traduit par une facture cloud qui ne baisse jamais.

Erreurs de configuration classiques

maxUnavailable: 0 ou minAvailable: 100%. Interdit toute éviction volontaire. Chaque drain bloque indéfiniment et l'autoscaler ne peut jamais récupérer le nœud. Cela ressemble à une sécurité maximale ; c'est un blocage opérationnel permanent.

Un seul réplica avec minAvailable: 1. L'unique pod ne peut jamais être évincé, donc tout drain de son nœud reste bloqué. Un PDB ne rend pas un workload mono-réplica hautement disponible ; il le rend seulement indrainable. La haute disponibilité commence par plusieurs réplicas, pas par un budget.

Des pourcentages sur de petits comptes de réplicas. Les pourcentages sont arrondis au supérieur, au pod entier le plus proche. minAvailable: 50% sur 3 réplicas donne 2, ce qui ne laisse la place qu'à une seule éviction, pas à la « moitié » imaginée. Faites le calcul pour votre nombre réel de réplicas avant de faire confiance à l'intention.

Un sélecteur qui vise les mauvais pods. Un PDB dont le sélecteur ne matche rien ne protège rien, en silence. Un sélecteur qui matche des pods appartenant à plusieurs contrôleurs empêche le contrôleur de calculer un nombre attendu à partir d'un pourcentage ou de maxUnavailable, et il refusera alors les évictions par prudence. Un PDB par workload, avec un sélecteur qui vise exactement ce workload.

Des pods cassés que vous ne pouvez pas évincer. Par défaut (unhealthyPodEvictionPolicy: IfHealthyBudget), un pod non-Ready ne peut être évincé que tant que le budget est satisfait. Si vous êtes déjà sous le plancher parce que des pods crashent, vous ne pouvez même plus évincer les pods cassés pour drainer le nœud : la récupération se bloque. Poser unhealthyPodEvictionPolicy: AlwaysAllow autorise l'éviction des pods non-Ready dans tous les cas, ce qui est généralement le comportement souhaité pour un drain fluide.

À retenir

Un PodDisruptionBudget est un limiteur de débit sur les évictions volontaires, pas une garantie de disponibilité. Il protège les opérations planifiées (drains, réductions par l'autoscaler, mises à jour de nœuds) contre le retrait de plus de pods que vous n'autorisez ; il ne fait rien contre les crashs de nœud, les OOM kills ou kubectl delete pod. Réglez-le avec maxUnavailable sur les workloads scalables, jamais à une valeur qui autorise zéro perturbation, jamais sur un réplica unique, et pensez à AlwaysAllow pour que des pods cassés ne coincent pas vos drains. Maîtriser ces primitives, c'est ce qui rend la maintenance de cluster ennuyeuse, et c'est tout l'objet de la fiabilité et de l'observabilité. Plus de contenu Kubernetes dans la catégorie kubernetes.

PodDisruptionBudget: What It Actually Protects Against

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "poddisruptionbudget", "pdb minavailable vs maxunavailable" and "kubectl drain stuck pdb" are global technical queries typed almost exclusively in English by engineers mid-operation. Consistent with the strategy of publishing pointed reference tutorials in English.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against Kubernetes documentation and controller behavior. No production anecdotes by design, this is not a REX. -->

Two symptoms send people to the PodDisruptionBudget docs, and they point in opposite directions. The first: kubectl drain node-7 hangs on "evicting pod ..." and never returns, the cluster autoscaler logs that it cannot scale down, a node-pool upgrade stalls on a single node for an hour. The second: a team adds a PDB expecting it to keep their app alive when a node dies, then loses half their replicas to a hardware failure anyway and wonders why the budget did nothing. Both come from the same misreading of what a PDB is actually for.

Voluntary versus involuntary disruptions

Kubernetes splits pod disruptions into two families, and a PDB touches exactly one of them.

Voluntary disruptions go through the Eviction API. That means kubectl drain, the cluster autoscaler removing an underused node, a managed node-pool rolling upgrade, or anything issuing a POST .../pods/<name>/eviction. These are deliberate actions initiated by an operator or a controller.

Involuntary disruptions are everything else: a kernel panic, hardware failure, the node running out of memory and the OOM killer taking your pod, a network partition, a preemption for a higher-priority pod. Note one entry that surprises people: kubectl delete pod is a direct delete, not an eviction, so the PDB never sees it either.

A PodDisruptionBudget is a gate in front of the Eviction API and nothing more. It cannot resurrect a pod that went down with its node, and it never schedules a replacement. If your concern is node crashes, the levers are replica count, topologySpreadConstraints and anti-affinity, not a PDB. What a budget buys you is protection against your own tooling removing too many pods at once during planned operations. It caps concurrent voluntary evictions so a drain or a scale-down cannot drop you below a floor you set.

minAvailable versus maxUnavailable

A PDB carries exactly one of two fields; they are mutually exclusive.

minAvailable: the number (or percentage) of pods that must stay healthy. An eviction is refused if it would push the count below this floor.
maxUnavailable: the number (or percentage) of pods allowed to be down at once. An eviction is refused once that many are already unavailable.

The disruption controller turns either one into a single computed value. It reads the expected pod count from the owning controller (a Deployment's spec.replicas, for example), counts how many pods are currently healthy (healthy meaning Ready, which is why your readiness probe directly feeds this math), and derives disruptionsAllowed = currentHealthy − desiredHealthy. With minAvailable: 4, desiredHealthy is 4. With maxUnavailable: 1 on 6 replicas, desiredHealthy is 5. When disruptionsAllowed reaches 0, the Eviction API returns HTTP 429 and kubectl drain backs off and retries until the budget reopens.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
spec:
  minAvailable: 4          # never drop below 4 Ready pods
  selector:
    matchLabels:
      app: api
  # unhealthyPodEvictionPolicy: AlwaysAllow   # see gotchas

$ kubectl get pdb api
NAME   MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
api    4               N/A               2                     3d

ALLOWED DISRUPTIONS: 2 means two pods can be evicted right now; drain a node holding three api pods and the third eviction waits.

Prefer maxUnavailable when you scale horizontally: it stays correct as replicas changes, whereas a fixed minAvailable silently becomes stricter as you scale down and looser as you scale up.

Interaction with drains and the cluster autoscaler

kubectl drain cordons the node, then evicts its pods one by one through the Eviction API, honoring every matching PDB. If a budget is exhausted, drain does not fail; it loops, waiting for pods to reschedule elsewhere and become Ready so the budget reopens. A drain that "hangs" is almost always a PDB doing its job while replacements are not coming up (no room to schedule, or a stuck rollout).

The cluster autoscaler leans on the same API for scale-down. Before removing an underused node it checks whether every pod on it can be evicted without violating a PDB. If not, the node is marked unremovable and stays. A PDB that can never allow a disruption therefore pins nodes in place and defeats consolidation, which shows up as a cloud bill that never shrinks.

Common misconfigurations

maxUnavailable: 0 or minAvailable: 100%. This forbids all voluntary evictions. Every drain blocks forever and the autoscaler can never reclaim the node. It reads like maximum safety; it is a permanent operational deadlock.

A single replica with minAvailable: 1. The one pod can never be evicted, so any drain of its node hangs indefinitely. A PDB cannot make a single-replica workload highly available; it can only make it un-drainable. Raise the replica count first, or accept that this pod takes brief downtime during node operations.

Percentages on small replica counts. Percentages round up to the nearest whole pod. minAvailable: 50% on 3 replicas resolves to 2, leaving room for only one eviction, not the "half" you pictured. Do the arithmetic for your actual replica count before trusting the intent.

A selector that matches the wrong pods. A PDB whose selector matches nothing silently guards nothing. A selector matching pods owned by several controllers leaves the disruption controller unable to compute an expected count from a percentage or maxUnavailable, and it will refuse evictions conservatively. One PDB per workload, selector matching exactly that workload.

Broken pods you cannot evict. By default (unhealthyPodEvictionPolicy: IfHealthyBudget), a not-Ready pod can be evicted only while the budget is currently met. If you are already below the floor because pods are crashing, you cannot even evict the broken ones to drain the node, so recovery deadlocks. Setting unhealthyPodEvictionPolicy: AlwaysAllow lets not-Ready pods be evicted regardless, which is usually what you want for a smooth drain.

What to remember

A PodDisruptionBudget is a rate limiter on voluntary evictions, not an availability guarantee. It protects planned operations (drains, autoscaler scale-down, node upgrades) from removing more pods than you allow; it does nothing about node crashes, OOM kills, or kubectl delete pod. Set it with maxUnavailable on scalable workloads, never at a value that allows zero disruptions, never on a single replica, and consider AlwaysAllow so broken pods do not wedge your drains. Getting these primitives right is what makes cluster maintenance boring, which is the whole point of reliability engineering. More Kubernetes material in the kubernetes category.

Readiness, Liveness and Startup Probes in Kubernetes

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "kubernetes readiness vs liveness probe" and "startupProbe" are global technical queries searched almost exclusively in English; the audience is the international SRE/platform crowd. Consistent with the site strategy of publishing pointed technical tutorials in English.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against the Kubernetes documentation and source behavior. No production anecdotes by design — this is not a REX. -->

Kubernetes has three probe types (readiness, liveness and startup), and they answer three different questions. Most probe-related outages come from treating them as one mechanism: the same /healthz endpoint pasted into both readinessProbe and livenessProbe, no startupProbe on an application that takes a minute to boot, and default timeouts nobody read. This is a reference for what each probe actually gates, the failure modes that follow from mixing them up, and how to choose the parameters.

Three probes, three different questions

All three probes share the same YAML shape and the same handlers. What differs is what the kubelet does with the result.

readinessProbe: can this pod serve traffic right now?

Readiness gates load balancing. While the probe passes, the pod's IP is listed in the EndpointSlices of every Service that selects it. When it fails (failureThreshold consecutive times), the pod is marked not-ready and removed from load balancing. The container is not touched: it keeps running, and the moment the probe passes again the pod goes back into rotation.

Readiness is the only probe designed to fail during normal operation. A pod that is momentarily overloaded, waiting on a cache warm-up, or draining before shutdown is exactly what "not ready" means. It runs for the whole life of the container, not just at startup.

Readiness failures also gate rollouts: a rolling update only proceeds past a new pod once that pod reports Ready. A wrong readiness check therefore has a second blast radius: it can let a rolling update replace working pods with broken ones that claim to be fine.

livenessProbe: is this process wedged beyond recovery?

Liveness gates container restarts. When it fails failureThreshold consecutive times, the kubelet kills the container and restarts it according to the pod's restartPolicy, with exponential backoff (CrashLoopBackOff when it keeps happening).

That is a brutal remedy, which is why the question liveness answers must be narrow: is the process deadlocked, wedged, or otherwise unable to make progress in a way that only a restart fixes? Anything softer than that belongs in readiness. A liveness probe should almost never fail in a healthy fleet. If yours fires regularly, either the app has a real defect or the probe is checking the wrong thing.

startupProbe: has this container finished booting?

Startup gates the other two probes. While a startupProbe is defined and has not yet succeeded, the kubelet does not run liveness or readiness at all. Once it succeeds a single time, it never runs again and the other probes take over.

Its purpose is slow-starting applications. The maximum boot time you grant is failureThreshold × periodSeconds (plus initialDelaySeconds if set); if the probe still has not succeeded by then, the container is killed and restarted. That budget lives in one place, on one probe, instead of being smeared across initialDelaySeconds on the other two.

Probe mechanics and parameters

Each probe uses one of four handlers:

httpGet: success is an HTTP status ≥ 200 and < 400. The most common choice for web workloads.
tcpSocket: success is completing a TCP connection. Proves a port is open, nothing about the application behind it.
exec: runs a command in the container; exit code 0 is success. Flexible, and the most expensive, since each execution forks inside the container.
grpc: uses the standard gRPC Health Checking Protocol (GA since Kubernetes 1.27). The right answer for gRPC servers, replacing the old grpc_health_probe exec workaround.

The timing parameters, with their defaults:

| Parameter | Default | Meaning | |---|---|---| | initialDelaySeconds | 0 | Wait before the first check | | periodSeconds | 10 | Interval between checks | | timeoutSeconds | 1 | Time allowed per check | | failureThreshold | 3 | Consecutive failures before acting | | successThreshold | 1 | Consecutive successes to recover (must be 1 for liveness and startup) |

Two defaults deserve attention. timeoutSeconds: 1 is aggressive: an exec probe that forks a shell, or an HTTP handler that touches anything slower than memory, can blow a one-second budget under load, and a probe timeout counts as a failure. periodSeconds: 10 with failureThreshold: 3 means detection takes up to 30 seconds, which is often slower than people assume their "health checks" react.

The failure modes of copy-pasted probes

These are the patterns that turn probes from a safety mechanism into an outage amplifier. All of them come from copying a working-looking block without asking which question it answers.

Liveness and readiness pointing at the same endpoint

The most common one. If /healthz fails because a downstream dependency is slow, readiness correctly pulls the pod out of rotation. Liveness, watching the same endpoint, then restarts a process that was never broken. Multiply by every replica watching the same slow dependency and you get a coordinated restart storm: the dependency recovers, but your application tier is now in CrashLoopBackOff.

The two probes need different endpoints because they answer different questions. /ready may consult whatever the app needs to serve a request; /live should verify only that the process itself is responsive.

Dependency checks inside the liveness probe

The generalized version of the previous mistake. A liveness handler that pings the database, checks a message broker, or calls another service converts every dependency blip into a mass restart of the dependents. Restarting your API pods does not fix your database; it adds connection churn and cold caches on top of the original problem, and it does so on every replica at roughly the same time.

Dependency awareness belongs in readiness, and even there with care: if every replica's readiness fails simultaneously because a shared dependency is down, the Service ends up with zero endpoints and clients get connection refused instead of a degraded response. For a dependency the app could partially work without, returning 200 with degraded behavior is often better than failing the probe.

No startupProbe on a slow-starting application

Without a startup probe, liveness starts checking after initialDelaySeconds. For an application with variable boot time (JVMs warming up, migrations running, large caches loading), that forces a bad choice: either set initialDelaySeconds high enough for the worst case, and eat that delay on every restart even the fast ones, or set it optimistically and watch the kubelet kill containers that were 5 seconds from finishing boot. The kill leads to a restart, which boots slowly again, which gets killed again: a startup crash loop caused entirely by probe configuration.

A startupProbe with a generous failureThreshold solves this cleanly:

startupProbe:
  httpGet:
    path: /live
    port: 8080
  periodSeconds: 5
  failureThreshold: 24      # up to 120 s to boot

The app gets up to two minutes to come up, checked every five seconds, so a fast boot is detected fast. Once it is up, liveness runs with tight, steady-state settings instead of settings inflated to cover booting.

No readinessProbe at all

Without a readiness probe, a pod counts as Ready as soon as its containers are running. Traffic arrives before the application listens, and rolling updates make progress based on that lie: old pods get killed because new ones claim to be "Ready". The result is a burst of errors on every deploy that no amount of liveness tuning can fix.

tcpSocket where httpGet was needed

A tcpSocket readiness probe on a web application proves the socket is open. An application can accept TCP connections long before its routes are wired, and long after its event loop has wedged. If the app speaks HTTP, probe it over HTTP.

A complete example

The three probes together, on a hypothetical app with an occasionally slow boot:

containers:
  - name: app
    ports:
      - containerPort: 8080
    startupProbe:
      httpGet:
        path: /live
        port: 8080
      periodSeconds: 5
      failureThreshold: 24        # boot budget: 120 s
    readinessProbe:
      httpGet:
        path: /ready              # may check what serving requires
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 2         # out of rotation within ~10 s
    livenessProbe:
      httpGet:
        path: /live               # process responsive, nothing else
        port: 8080
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 3         # restart only after ~30 s of silence

Note the asymmetry: readiness reacts faster than liveness (failureThreshold: 2 vs 3, shorter period). Being pulled from load balancing is cheap and reversible; a restart is neither. You want the cheap remedy to trigger first.

Decision table

| Question | Probe | On failure | Endpoint should check | |---|---|---|---| | Can this pod take traffic now? | readinessProbe | Removed from Service endpoints | App fully initialized; critical dependencies, with care | | Is the process wedged beyond recovery? | livenessProbe | Container killed and restarted | Process/event loop responsiveness only, never dependencies | | Has the container finished booting? | startupProbe | Container killed and restarted | Same handler as liveness, generous failureThreshold |

And for the parameters:

| Situation | Setting | |---|---| | Boot time is variable or > ~10 s | Add a startupProbe; keep initialDelaySeconds at 0 elsewhere | | Handler does real work (exec, disk, downstream call) | Raise timeoutSeconds above the default 1 s | | Traffic must leave a bad pod quickly | Lower readiness periodSeconds × failureThreshold product | | Restarts are expensive (caches, connections) | Raise liveness failureThreshold; make the handler trivial | | gRPC server | Use the grpc handler, not an exec workaround |

What probes do not solve

Two boundaries worth knowing. First, a correct readinessProbe does not give you zero-downtime deploys: pod termination during a rollout is a propagation race that readiness cannot influence, and fixing it involves preStop hooks and SIGTERM handling — the moving parts are summarized in the glossary entry on rolling deployments (in French). Second, probes keep working under a default-deny NetworkPolicy: the kubelet probes pods from the node itself and CNIs exempt that host-local traffic, a detail that matters when rolling out a default-deny NetworkPolicy.

The mental model that survives contact with production is small: readiness is a routing decision, liveness is a restart decision, startup is a boot-time budget. Configure each one to answer only its own question, give the cheap remedy a faster trigger than the brutal one, and read the defaults before trusting them. Getting probes to answer honestly is one small piece of a larger discipline, making a platform surface its own failures before users do, which is what my reliability and observability work (in French) is about. More Kubernetes material in the kubernetes category.

Kubernetes requests vs limits: throttling, OOMKill and QoS

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "kubernetes requests vs limits", "cpu throttling", "OOMKilled" are global technical queries searched almost entirely in English; the audience is the international SRE/platform crowd. Consistent with the site strategy of publishing pointed technical tutorials in English. Paired with the French version via translationKey.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against the Kubernetes documentation, cgroup behavior and cAdvisor metrics. No production anecdotes by design, this is not a REX. -->

A pod runs fine, then vanishes with OOMKilled and exit code 137. A different pod is slow under load while the node it sits on is 70% idle. Both symptoms trace back to the same two fields most manifests set by reflex and few people read closely: requests and limits. They are not two dials for the same thing. They act at different moments, on different subsystems, with very different consequences when you cross them.

Requests and limits do different jobs

A request is a scheduling input. The scheduler bin-packs pods by summing their requests against a node's allocatable capacity; a request is a reservation and the floor the pod is guaranteed to get. It never caps usage.

A limit is a runtime ceiling enforced by the kubelet and the kernel through cgroups. What happens when a container hits that ceiling depends entirely on which resource you are talking about, because CPU and memory behave in opposite ways.

Crossing the CPU limit: throttling

CPU is a compressible resource. The kernel can hand a process fewer cycles without killing it.

The CPU request becomes a cgroup weight (cpu.shares under cgroup v1, cpu.weight under v2, where one core maps to 1024 shares). That weight only matters under contention: it decides how idle-starved processes split a saturated CPU. When the node has spare capacity, everyone runs freely regardless of requests.

The CPU limit becomes CFS bandwidth control: a quota per scheduling period (cpu.cfs_quota_us / cpu.cfs_period_us, or cpu.max on v2), with a default 100 ms period. A limit of 500m grants 50 ms of CPU per 100 ms window. Spend that budget before the window closes and the container is throttled, parked until the next period. No kill, just latency.

The trap lives in that per-period enforcement. Throttling fires whether or not the node is busy, so a bursty, latency-sensitive workload can be throttled hard while the machine sits mostly idle. Watch the ratio of container_cpu_cfs_throttled_periods_total to container_cpu_cfs_periods_total; a high value is CFS throttling, not a slow application.

Crossing the memory limit: OOMKill

Memory is incompressible. You cannot ask a process to hold less RAM the way you can give it fewer cycles.

The memory request feeds scheduling and eviction ranking; it is not a cap. The memory limit is a hard cap (memory.max / memory.limit_in_bytes). Touch one byte past it and the cgroup OOM killer sends SIGKILL to a process inside the cgroup. Kubernetes reports the container as OOMKilled, exit code 137 (128 + SIGKILL), restarts it per restartPolicy, and lands in CrashLoopBackOff if it keeps happening.

Two distinct memory events are easy to confuse. Hitting your own container's limit is a cgroup OOMKill: kernel-level, immediate, scoped to that pod. The node running low on memory overall triggers kubelet eviction instead, which ranks victims by QoS class and by how far each pod has grown above its request.

QoS classes are derived, not declared

Kubernetes assigns each pod a class from what you set:

Guaranteed: every container sets requests == limits for both CPU and memory. It gets a strongly negative oom_score_adj (-997) and is evicted last.
Burstable: at least one request or limit is set, but the pod is not Guaranteed.
BestEffort: nothing set at all. It gets oom_score_adj 1000 and is the first to be evicted and the first the kernel kills under memory pressure.

The class is not cosmetic. Under node pressure it decides who dies first, and that ordering is the whole point of setting requests honestly.

The "no CPU limits" argument

This is a genuine, ongoing debate. The case for dropping CPU limits: CFS throttling costs latency even on an idle node, and a CPU request already guarantees a proportional share under contention, so a limit often just buys you throttling you never needed. The case for keeping them: predictable capacity planning, protection from a runaway neighbour, and the fact that CPU limits are required for the Guaranteed class and for static CPU pinning.

The pragmatic middle most platform teams land on: almost always set memory request == limit (incompressible resource, you want a hard and predictable cap), always set a CPU request, and treat CPU limits as optional, applied only where a specific policy demands one.

A method for setting defaults

Measure, do not guess. Use the Vertical Pod Autoscaler in recommendation mode (updateMode: "Off") or query Prometheus history directly. The same measure-first reflex applies to metric cardinality: observe before you tune, not the other way round.

# peak memory working set over 7 days, per pod
max_over_time(container_memory_working_set_bytes{container="app"}[7d])

# 95th percentile of CPU cores used over 7 days
quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container="app"}[5m])[7d:5m])

Then set values from those numbers:

resources:
  requests:
    cpu: 250m           # typical usage, drives scheduling
    memory: 512Mi
  limits:
    memory: 512Mi       # equal to request: hard, predictable cap
    # no cpu limit: bursts into idle capacity, still guaranteed 250m under contention

Memory request == limit set to the observed peak working set plus roughly 20 to 30% headroom. CPU request at typical usage (P90-ish), CPU limit left off unless a policy needs one. Re-measure once real traffic lands; your first numbers are a hypothesis, not a verdict.

Common pitfalls

Setting only a limit makes Kubernetes copy it into the request, which can silently over-reserve the node. Copying another team's numbers ignores that requests are workload-specific: too high wastes nodes, too low overcommits and invites eviction. Sizing memory off RSS instead of working set misses page cache the kernel counts against your limit. And blaming the application for latency that is actually CFS throttling wastes days; check the throttling ratio before you profile code.

What to remember

Requests are for the scheduler, limits are for the kernel. Over the CPU limit you get throttled, over the memory limit you get killed. Set memory request == limit, set a CPU request, be deliberate about CPU limits, and derive every number from measured usage rather than a template. Restarts from an OOMKill and restarts from a failing liveness probe look identical in kubectl describe, so it is worth knowing how probes actually behave before you debug the wrong one. Getting resource sizing right across a whole fleet is a good chunk of what makes a move to Kubernetes hold up in production instead of paging you later, and it is the heart of my legacy-to-Kubernetes migration work (in French). More Kubernetes material in the kubernetes category.

kubectl rollout undo : comment fonctionnent les rollbacks

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=fr justification : version française d'un tutoriel de référence générique, alignée sur l'amendement §2.4 (i18n systématique pour le contenu factuel générique). L'original EN vise la longue traîne technique mondiale ; cette version relaie sur LinkedIn FR et couvre les requêtes francophones ("rollback kubernetes", "revenir en arrière deployment").

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout face à la documentation Kubernetes et au comportement des contrôleurs. Aucune anecdote de production par construction, ce n'est pas un REX. -->

kubectl rollout undo a tout du bouton « annuler » : mauvais déploiement, une commande, retour au calme. C'est à peu près le cas. Mais ce qu'il restaure, jusqu'où il peut remonter et ce qui se passe quand un contrôleur GitOps surveille le même Deployment obéissent à des mécaniques qu'il vaut mieux comprendre avant le mauvais déploiement. Voici comment les rollbacks de Deployment Kubernetes fonctionnent réellement : où vivent les révisions, ce que rollout undo restaure ou non, et pourquoi dans un pipeline GitOps le vrai rollback est un revert Git.

Les révisions sont des ReplicaSets, pas des snapshots

Un Deployment ne conserve pas l'historique de ses specs passées. À chaque modification du template de pod (spec.template : image, variables d'environnement, sondes, labels des pods), le contrôleur de Deployment calcule un hash du nouveau template et crée un ReplicaSet nommé d'après ce hash, puis scale le nouveau ReplicaSet vers le haut et l'ancien vers le bas selon la stratégie de rollout. L'ancien ReplicaSet n'est pas supprimé : il reste à 0 réplica, tout en conservant le template de pod exact avec lequel il a été créé.

Ce ReplicaSet mis à la retraite est la révision. La comptabilité tient dans une seule annotation :

$ kubectl get rs -l app=my-app
NAME                  DESIRED   CURRENT   READY   AGE
my-app-5d8c7b9f6d     0         0         0       2d    # revision 1
my-app-7f9b4c8d5e     0         0         0       1d    # revision 2
my-app-6c5d9e8f7a     3         3         3       2h    # revision 3

$ kubectl get rs my-app-7f9b4c8d5e \
    -o jsonpath='{.metadata.annotations.deployment\.kubernetes\.io/revision}'
2

kubectl rollout history deployment/my-app n'est en substance qu'un formateur d'affichage au-dessus de ces annotations. Deux conséquences en découlent directement :

Une révision n'enregistre que le template de pod. Le nombre de réplicas, les réglages du HPA, les labels et annotations propres au Deployment, et tout ce qui vit en dehors de spec.template n'en font pas partie.
Si le ReplicaSet a disparu, la révision aussi. Il n'en existe aucune autre copie.

Une subtilité : si vous déployez un template identique à celui que détient déjà un ancien ReplicaSet, le contrôleur réutilise ce ReplicaSet au lieu d'en créer un doublon, et son annotation de révision est incrémentée au numéro le plus récent (les numéros précédents sont conservés dans une annotation deployment.kubernetes.io/revision-history). Les révisions se dédupliquent par contenu.

Ce que rollout undo fait réellement

# retour à la révision précédente
kubectl rollout undo deployment/my-app

# retour à une révision précise
kubectl rollout history deployment/my-app
kubectl rollout history deployment/my-app --revision=2   # inspecter avant de sauter
kubectl rollout undo deployment/my-app --to-revision=2

rollout undo retrouve le ReplicaSet de la révision cible, prend son template de pod et le réinjecte dans le spec.template du Deployment. C'est tout. Il n'existe pas de marche arrière spéciale : le patch déclenche un rolling update ordinaire vers l'avant jusqu'à l'ancien template, en utilisant la strategy, les sondes, le maxSurge et le maxUnavailable habituels du Deployment. Un rollback est exactement aussi rapide, et exactement aussi sûr, que vos rollouts habituels. Si vos déploiements perdent des requêtes en cours de route, vos rollbacks aussi, une raison de plus de bien régler votre rolling deployment avant d'en avoir besoin sous pression.

La numérotation des révisions après un undo surprend. Revenir à la révision 2 ne « ramène pas à la révision 2 » : le template de la révision 2 devient la nouvelle révision la plus récente (disons la révision 4), et l'entrée d'historique du 2 disparaît, son contenu vit désormais tout en haut. Les numéros de révision ne font que croître ; rollout history est un journal de templates, pas une chronologie que l'on rembobine.

$ kubectl rollout undo deployment/my-app --to-revision=2
deployment.apps/my-app rolled back

$ kubectl rollout history deployment/my-app
REVISION  CHANGE-CAUSE
1         <none>
3         <none>
4         <none>      # c'est l'ancienne révision 2, renumérotée

Ce qu'un rollback ne restaure pas

Puisqu'une révision n'est qu'un template de pod, plusieurs choses que l'on attend d'un « annuler » sortent de son périmètre.

Le nombre de réplicas

Le scaling ne crée pas de révision : replicas vit en dehors de spec.template, donc kubectl scale ne laisse aucune trace dans rollout history. De façon symétrique, rollout undo ne touche jamais au nombre de réplicas : si vous êtes passé de 3 à 10 après le mauvais déploiement, vous êtes toujours à 10 après le undo. C'est généralement ce que vous voulez ; la surprise vient quand on s'attend à ce que le undo annule aussi un scale-down accidentel. Il ne le fera pas. Le scaling et le template sont deux axes indépendants.

ConfigMaps, Secrets, et tout ce qui entoure le pod

Le template de pod référence une ConfigMap ou un Secret par son nom. Si le mauvais déploiement a aussi modifié le contenu de la ConfigMap, revenir en arrière sur le Deployment remonte la même ConfigMap, toujours modifiée. Idem pour les migrations de base de données, les CRDs, les changements de RBAC, ou tout ce que votre release a touché en dehors de spec.template. rollout undo revient en arrière sur un champ d'un seul objet.

(La parade standard consiste à utiliser des noms immuables, hashés sur le contenu, comme app-config-7d9f2b, pour qu'un rollback de template ramène mécaniquement l'ancienne config. Le configMapGenerator de Kustomize et les annotations de checksum de Helm existent tous les deux pour cette raison.)

Tout ce qu'a fait un Deployment en pause

Vous ne pouvez pas revenir en arrière sur un Deployment en pause ; kubectl rollout undo refuse jusqu'à ce que vous fassiez kubectl rollout resume. Si vous utilisez pause/resume pour regrouper des changements, gardez en tête que la période de pause produit une seule révision, pas une par changement : la granularité du undo est le resume, pas l'édition.

revisionHistoryLimit : jusqu'où vous pouvez remonter

Le contrôleur de Deployment fait le ménage des anciens ReplicaSets au-delà de spec.revisionHistoryLimit, qui vaut 10 par défaut. Les révisions plus anciennes sont supprimées, et avec elles la possibilité d'y revenir :

$ kubectl rollout undo deployment/my-app --to-revision=1
error: unable to find specified revision 1 in history

Les deux extrémités du curseur :

revisionHistoryLimit: 0 supprime immédiatement tout ReplicaSet inactif. Cela rend le rollback impossible, point final. Parfois proposé au nom du « nettoyage », c'est en réalité la suppression de votre filet de sécurité.
Une limite élevée ne coûte presque rien (les ReplicaSets retirés sont de petits objets d'API sans aucun pod), mais notez que les pipelines bavards consomment l'historique vite. Dix déploiements dans une journée chargée, et la révision known-good d'hier peut déjà être hors de portée le temps que quelqu'un remarque une régression lente.

Dix est une valeur par défaut raisonnable pour un pipeline piloté par le repo. Si votre stratégie de rollback dépend réellement de rollout undo (voir plus bas pourquoi ce ne devrait peut-être pas être le cas), dimensionnez la limite en fonction de votre fréquence de déploiement, pas de la valeur par défaut.

Le change-cause manquant, et savoir vers quoi on revient

rollout history a une colonne CHANGE-CAUSE qui affiche <none> sur la plupart des clusters, parce qu'elle est renseignée depuis l'annotation kubernetes.io/change-cause, que rien ne pose automatiquement. L'ancien flag kubectl --record qui la remplissait est déprécié depuis des années. Vous pouvez la poser à la main :

kubectl annotate deployment/my-app \
  kubernetes.io/change-cause="release 2026-07-24, image v1.42.1"

L'annotation est copiée sur le ReplicaSet au moment du rollout, donc chaque révision garde sa propre cause. En pratique, les annotations maintenues à la main pourrissent. La manière fiable d'identifier une révision consiste à regarder son template réel :

kubectl rollout history deployment/my-app --revision=3
# ...affiche le template de pod : tag d'image, env, ce qui a réellement changé

Un undo à l'aveugle, c'est-à-dire rollout undo sans vérifier ce que contient la révision précédente, est un pari : celui que le déploiement précédent était le seul changement récent. Trente secondes d'inspection avec --revision=N sont une assurance bon marché ; cela vaut double quand l'historique a déjà été renuméroté par un undo antérieur.

rollout undo face à un revert Git

Si vos Deployments sont appliqués par un pipeline ou un contrôleur GitOps depuis des manifests dans Git, rollout undo pose un problème structurel : il modifie le cluster, pas le repo. Le Deployment dans le cluster et le manifest dans Git sont désormais en désaccord, et tout le mécanisme que vous avez construit existe précisément pour éliminer ce désaccord.

Avec un pipeline CI (kubectl apply au merge) : le undo tient jusqu'au prochain merge, moment où le pipeline réapplique les manifests, y compris le mauvais tag d'image que vous aviez fui. Le rollback se dé-fait silencieusement, peut-être des jours plus tard, déployé par un changement sans rapport.
Avec un contrôleur GitOps (Argo CD, Flux) : le contrôleur détecte le drift à sa prochaine synchronisation. Avec le self-heal activé, il annule votre rollback en quelques minutes. Le contrôleur fait son travail, qui est de rendre le cluster conforme à Git. Le combattre à coups de undo répétés, c'est combattre votre propre outillage ; le seul contournement est de désactiver l'auto-sync, ce qui sacrifie la garantie même pour laquelle GitOps existe.

Le rollback qui colle au modèle est un revert Git : reverter le commit qui a changé le tag d'image (ou le bump de release), laisser le pipeline ordinaire l'appliquer. Vous conservez la piste d'audit, la revue de diff, les checks CI qui gardent vos manifests, et surtout la garantie que Git décrit toujours ce qui tourne. Le compromis est honnête : un revert passe par le pipeline et prend quelques minutes, là où rollout undo agit en quelques secondes. Un motif d'urgence défendable consiste à utiliser rollout undo comme mesure d'arrêt qui stoppe l'hémorragie, puis à pousser immédiatement le revert Git pour que le repo s'accorde avec ce que vous venez de faire, et à traiter tout undo non suivi d'un commit comme une action de post-mortem, pas comme un correctif. Si votre pipeline est assez lent pour que cet écart paraisse dangereux, c'est le pipeline qu'il faut réparer ; rendre les déploiements et les rollbacks ennuyeux est exactement l'objectif de l'industrialisation de votre CI/CD.

Aide-mémoire

kubectl rollout history deployment/my-app                 # lister les révisions
kubectl rollout history deployment/my-app --revision=3    # en inspecter une
kubectl rollout undo deployment/my-app                    # reculer d'une révision
kubectl rollout undo deployment/my-app --to-revision=3    # revenir à une révision précise
kubectl rollout status deployment/my-app                  # regarder converger

Et les pièges en une passe : les révisions sont des ReplicaSets retirés et n'enregistrent que le template de pod ; le undo est un rolling update ordinaire vers l'avant et renumérote l'historique ; il ne restaure ni le nombre de réplicas ni les ConfigMaps ; revisionHistoryLimit (10 par défaut, jamais 0) borne la distance à laquelle vous pouvez remonter ; un Deployment en pause refuse de revenir en arrière ; et sous GitOps, le rollback durable est le revert Git, rollout undo n'en étant au mieux que la première moitié. D'autres ressources d'automatisation dans la catégorie automatisation.

kubectl rollout undo: How Kubernetes Rollbacks Work

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "kubectl rollout undo", "kubernetes rollback deployment" and "revisionHistoryLimit" are global technical queries searched almost exclusively in English by engineers mid-incident. Consistent with the strategy of publishing pointed tutorials in English.

kubectl rollout undo looks like an undo button: bad deploy, one command, back to safety. It mostly is one. But what it restores, how far back it can reach, and what happens when a GitOps controller is watching the same Deployment are all governed by mechanics worth understanding before the bad deploy. This is how Kubernetes Deployment rollbacks actually work: where revisions live, what rollout undo does and does not restore, and why in a GitOps pipeline the real rollback is a Git revert.

Revisions are ReplicaSets, not snapshots

A Deployment does not store a history of its past specs. Every time you change the pod template (spec.template: image, env vars, probes, labels on the pods), the Deployment controller computes a hash of the new template and creates a ReplicaSet named after it, then scales the new ReplicaSet up and the old one down according to the rollout strategy. The old ReplicaSet is not deleted: it stays at 0 replicas, still holding the exact pod template it was created with.

That retired ReplicaSet is the revision. The bookkeeping is a single annotation:

$ kubectl get rs -l app=my-app
NAME                  DESIRED   CURRENT   READY   AGE
my-app-5d8c7b9f6d     0         0         0       2d    # revision 1
my-app-7f9b4c8d5e     0         0         0       1d    # revision 2
my-app-6c5d9e8f7a     3         3         3       2h    # revision 3

$ kubectl get rs my-app-7f9b4c8d5e \
    -o jsonpath='{.metadata.annotations.deployment\.kubernetes\.io/revision}'
2

kubectl rollout history deployment/my-app is essentially a pretty-printer over these annotations. Two consequences follow directly:

A revision only records the pod template. Replica count, HPA settings, the Deployment's own labels and annotations, and anything outside spec.template are not part of it.
If the ReplicaSet is gone, the revision is gone. There is no other copy.

One wrinkle: if you roll out a template identical to one an old ReplicaSet already holds, the controller reuses that ReplicaSet rather than creating a duplicate, and its revision annotation is bumped to the newest number (the previous numbers are kept in a deployment.kubernetes.io/revision-history annotation). Revisions deduplicate by content.

What rollout undo actually does

# back to the previous revision
kubectl rollout undo deployment/my-app

# back to a specific revision
kubectl rollout history deployment/my-app
kubectl rollout history deployment/my-app --revision=2   # inspect before jumping
kubectl rollout undo deployment/my-app --to-revision=2

rollout undo finds the target revision's ReplicaSet, takes its pod template, and patches it back into the Deployment's spec.template. That is all. There is no special reverse gear: the patch triggers an ordinary rolling update forward to the old template, using the Deployment's normal strategy, probes, maxSurge and maxUnavailable. A rollback is exactly as fast, and exactly as safe, as your regular rollouts are. If your deploys drop requests mid-rollout, your rollbacks will too, which is one more reason to get your rolling deployment settings right before you need one under pressure.

The revision numbering after an undo surprises people. Rolling back to revision 2 does not "return to revision 2": the template of revision 2 becomes the new latest revision (say, revision 4), and the history entry for 2 disappears — its content now lives at the top. Revision numbers only ever increase; rollout history is a log of templates, not a timeline you rewind.

$ kubectl rollout undo deployment/my-app --to-revision=2
deployment.apps/my-app rolled back

$ kubectl rollout history deployment/my-app
REVISION  CHANGE-CAUSE
1         <none>
3         <none>
4         <none>      # this is the old revision 2, renumbered

What a rollback does not restore

Because a revision is only a pod template, several things people expect from an "undo" are out of scope.

Replica count

Scaling does not create a revision: replicas sits outside spec.template, so kubectl scale leaves no trace in rollout history. Symmetrically, rollout undo never touches the replica count: if you scaled from 3 to 10 after the bad deploy, you are still at 10 after the undo. Usually that is what you want; the surprise is when someone expects undo to also revert an accidental scale-down. It will not. Scale and template are independent axes.

ConfigMaps, Secrets, and everything around the pod

The pod template references a ConfigMap or Secret by name. If the bad deploy also changed the ConfigMap's contents, rolling back the Deployment re-mounts the same, still-changed ConfigMap. The same applies to database migrations, CRDs, RBAC changes, or anything else your release touched outside spec.template. rollout undo rolls back one field of one object.

(The standard mitigation is immutable, content-hashed names like app-config-7d9f2b, so a template rollback mechanically brings back the old config. Kustomize's configMapGenerator and Helm's checksum annotations both exist for this reason.)

Anything a paused Deployment did

You cannot roll back a paused Deployment; kubectl rollout undo refuses until you kubectl rollout resume it. If you use pause/resume to batch changes, remember that the paused period produces a single revision, not one per change: the undo granularity is the resume, not the edit.

revisionHistoryLimit: how far back you can reach

The Deployment controller garbage-collects old ReplicaSets beyond spec.revisionHistoryLimit, which defaults to 10. Older revisions are deleted, and with them the ability to roll back to them:

$ kubectl rollout undo deployment/my-app --to-revision=1
error: unable to find specified revision 1 in history

Two edges of the dial:

revisionHistoryLimit: 0 deletes every inactive ReplicaSet immediately. It makes rollback impossible, full stop. Occasionally proposed as "cleanup"; it is the removal of your safety net.
A high limit costs almost nothing (retired ReplicaSets are small API objects with zero pods), but note that noisy pipelines burn through history fast. Ten deploys on a busy day means yesterday's known-good revision may already be beyond reach by the time someone notices a slow regression.

Ten is a reasonable default for a repo-driven pipeline. If your rollback strategy genuinely depends on rollout undo (see below for why it maybe should not), size the limit against your deploy frequency, not the default.

The missing change-cause, and knowing what you are rolling back to

rollout history has a CHANGE-CAUSE column that is <none> on most clusters, because it is populated from the kubernetes.io/change-cause annotation, which nothing sets automatically. The old kubectl --record flag that filled it has been deprecated for years. You can set it by hand:

kubectl annotate deployment/my-app \
  kubernetes.io/change-cause="release 2026-07-24, image v1.42.1"

The annotation is copied to the ReplicaSet at rollout time, so each revision keeps its own cause. In practice, hand-maintained annotations rot. The reliable way to identify a revision is to look at its actual template:

kubectl rollout history deployment/my-app --revision=3
# ...prints the pod template: image tag, env, the thing that actually changed

An undo done blind, meaning rollout undo without checking what the previous revision contains, is a gamble that the previous deploy was the only recent change. Thirty seconds of --revision=N inspection is cheap insurance; this matters double when history has been renumbered by an earlier undo.

rollout undo vs a Git revert

If your Deployments are applied by a pipeline or a GitOps controller from manifests in Git, rollout undo has a structural problem: it changes the cluster, not the repo. The Deployment in the cluster and the manifest in Git now disagree, and every mechanism you have built exists to eliminate exactly that disagreement.

With a CI pipeline (kubectl apply on merge): the undo holds until the next merge, at which point the pipeline re-applies the manifests, including the bad image tag you rolled away from. The rollback silently un-rolls itself, possibly days later, deployed by an unrelated change.
With a GitOps controller (Argo CD, Flux): the controller detects the drift on its next sync. With self-heal enabled, it reverts your rollback within minutes. The controller is doing its job, which is making the cluster match Git. Fighting it with repeated undos is fighting your own tooling; the only workaround is disabling auto-sync, which trades away the guarantee GitOps exists to provide.

The rollback that fits the model is a Git revert: revert the commit that changed the image tag (or the release bump), let the ordinary pipeline apply it. You keep the audit trail, the diff review, whatever CI checks guard your manifests, and, critically, the guarantee that Git still describes what runs. The trade-off is honest: a revert goes through the pipeline and takes minutes, while rollout undo acts in seconds. A defensible emergency pattern is to use rollout undo as the stopgap that stops the bleeding, then immediately push the Git revert so the repo agrees with what you just did, and treat any undo that is not followed by a commit as an incident action item, not a fix. If your pipeline is slow enough that this gap feels dangerous, the pipeline is the thing to fix; making deploys and rollbacks boring is precisely the point of industrializing your CI/CD.

Quick reference

kubectl rollout history deployment/my-app                 # list revisions
kubectl rollout history deployment/my-app --revision=3    # inspect one
kubectl rollout undo deployment/my-app                    # back one revision
kubectl rollout undo deployment/my-app --to-revision=3    # back to a specific one
kubectl rollout status deployment/my-app                  # watch it converge

And the gotchas in one pass: revisions are retired ReplicaSets and record only the pod template; undo is a normal rolling update forward and renumbers history; it restores neither replica count nor ConfigMaps; revisionHistoryLimit (default 10, never 0) bounds how far back you can go; a paused Deployment refuses to roll back; and under GitOps, the durable rollback is the Git revert — rollout undo is at best the first half of one. More automation material in the automatisation category.

Symptom-based Prometheus alerts that don't page at 3am

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "prometheus alerting best practices", "symptom based alerting", "prometheus for clause" are global technical queries searched almost exclusively in English. Reference tutorial for the international SRE/platform audience, consistent with the site strategy of publishing pointed technical material in English.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against Prometheus and Alertmanager documented behavior. No production anecdotes by design; this is not a REX. -->

It is 3am and the pager fires: HighCPUUsage, node at 92%. You open a laptop, look around, and everything works. Users are asleep, the batch job that spiked CPU finished on its own, and you go back to bed annoyed. Two weeks of that and people start muting the channel. The alert was technically correct and completely useless, because it told you about a cause that may or may not have a symptom.

The single most useful idea in alerting is this: page a human on symptoms, and let causes stay on dashboards. High CPU is not a problem. Slow responses are. If the CPU is at 92% and the service still meets its latency target, there is nothing to do. Alert on the thing your users actually feel, and you get a pager that means "something is broken right now" instead of "a number crossed a line".

Symptom-based versus cause-based

A cause-based rule watches an internal resource: CPU, memory, queue depth, disk usage. A symptom-based rule watches the contract with the user: error rate, latency, availability. The problem with cause-based alerting is that the mapping from cause to symptom is not one-to-one. High CPU sometimes hurts and usually does not. A full disk is a genuine emergency on a database node and a shrug on a stateless replica. Every cause needs a human to decide whether it matters, at 3am, which is exactly the decision the alert was supposed to make for you.

This does not mean deleting your resource metrics. Keep them; they are how you diagnose an incident once a symptom alert has woken you. The rule of thumb: symptoms page, causes inform. Disk-filling and certificate-expiry are the honest exceptions, because they are causes with a guaranteed, predictable symptom in the near future, so alerting early is the whole point.

How `for` and severity actually work

Prometheus evaluates alerting rules every evaluation_interval (1 minute by default). When a rule's expression returns samples, the matching alerts enter the pending state. They only become firing, and get sent to Alertmanager, once the expression has stayed true continuously for the duration in the for field. A single evaluation where the expression returns nothing resets the timer.

That for clause is your first and cheapest noise filter. An expression with no for fires on a single scrape, so one slow scrape or one transient spike pages you. for: 10m says "I only care if this is still true ten minutes from now", which filters out exactly the self-healing blips that generate 3am false alarms. The trade-off is detection latency, so tune it per symptom: a hard-down service might use for: 2m, a slow latency creep for: 15m.

Severity is a plain label, not a built-in feature. The convention is severity: critical for "wake someone up" and severity: warning for "look at it during business hours". The label carries no meaning to Prometheus itself; it becomes useful in Alertmanager routing, where you send critical to the pager and warning to a chat channel. Getting the split right is most of what separates a calm on-call rotation from a burned-out one. If everything is critical, nothing is.

A bad rule rewritten into a good one

Here is a rule that looks reasonable and pages constantly:

groups:
  - name: bad.rules
    rules:
      - alert: HighCPUUsage
        expr: rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.8
        labels:
          severity: critical
        annotations:
          summary: "CPU is high"

Everything about it invites fatigue. It fires per core rather than per node, has no for so a single spike pages, calls a resource-usage number critical, and the annotation tells the responder nothing they can act on. Rewritten around a symptom:

groups:
  - name: good.rules
    rules:
      - alert: HighRequestErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
            /
          sum(rate(http_requests_total[5m])) by (service)
            > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.service }} is serving >5% errors"
          description: "5xx error ratio is {{ $value | humanizePercentage }} over 5m. Check recent deploys and downstream dependencies."
          runbook_url: "https://runbooks.internal/high-error-rate"

The good rule alerts on what a user experiences (a failed request), is aggregated to a meaningful unit (per service), survives a transient blip (for: 10m), and hands the responder a starting point through its annotations and a runbook link. Deciding where to set that 5% threshold is a job for an error budget and a defined service level objective rather than a number you invent at the keyboard. And this rule assumes the right metrics already exist: the error rate and latency queried here come from an application instrumented to expose them, a prerequisite covered in instrumenting an app for Prometheus.

Pitfalls that survive good intentions

Three traps recur even in symptom-based setups. First, the divide-by-zero: a ratio like the one above produces no result when a service gets no traffic, so an outage that stops all requests can silence the very alert meant to catch it. Pair error-rate alerts with a low-traffic or absence check. Second, over-eager thresholds without burn-rate awareness: a flat "5% for 10m" both misses a slow burn that quietly eats the month's budget and screams during a brief spike, which is why multi-window, multi-burn-rate alerting exists. Third, critical inflation: every alert added as critical because "it felt important" trains the on-call to ignore the pager, and a muted pager is worse than no pager.

What to keep

Alert on symptoms, keep causes for diagnosis. Use for to filter self-healing noise, and reserve critical for things that genuinely need a human out of bed. Write annotations for the tired person reading them at 3am, not for yourself writing them at 3pm. An alerting stack built this way is a core deliverable of a reliability and observability engagement. More in the observability category, and the same discipline applied to probes lives in Kubernetes readiness and liveness probes.

Probes Kubernetes : readiness, liveness et startup

Fri, 24 Jul 2026 00:00:00 GMT

<!-- justification lang=fr : version française de l'article EN "kubernetes-readiness-liveness-startup-probes". Le contenu est un tutoriel de référence générique ; la traduction FR sert le public francophone (relais LinkedIn FR) et le maillage interne vers le glossaire français. Paire liée via translationKey.

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre la documentation Kubernetes et le comportement des sources. Aucune anecdote de production par construction, ce n'est pas un REX. -->

Kubernetes dispose de trois types de probes (readiness, liveness et startup), et chacune répond à une question différente. La plupart des incidents liés aux probes viennent du fait qu'on les traite comme un seul mécanisme : le même endpoint /healthz collé dans readinessProbe et dans livenessProbe, aucun startupProbe sur une application qui met une minute à démarrer, et des timeouts par défaut que personne n'a lus. Voici une référence de ce que chaque probe contrôle vraiment, des modes de défaillance qui découlent de leur confusion, et de la manière d'en choisir les paramètres.

Trois probes, trois questions différentes

Les trois probes partagent la même structure YAML et les mêmes handlers. Ce qui change, c'est ce que le kubelet fait du résultat.

readinessProbe : ce pod peut-il servir du trafic maintenant ?

La readiness contrôle le load balancing. Tant que la probe passe, l'IP du pod figure dans les EndpointSlices de chaque Service qui le sélectionne. Quand elle échoue (failureThreshold fois de suite), le pod est marqué not-ready et retiré du load balancing. Le conteneur n'est pas touché : il continue de tourner, et dès que la probe repasse au vert le pod revient dans la rotation.

La readiness est la seule probe conçue pour échouer en fonctionnement normal. Un pod momentanément surchargé, en attente d'un préchauffage de cache, ou en train de se vider avant un arrêt correspond exactement à ce que « not ready » veut dire. Elle tourne pendant toute la vie du conteneur, pas seulement au démarrage.

Les échecs de readiness conditionnent aussi les rollouts : une mise à jour progressive ne dépasse un nouveau pod que lorsque celui-ci se déclare Ready. Un contrôle de readiness mal fichu a donc un second rayon d'action : il peut laisser un rolling update remplacer des pods sains par des pods cassés qui prétendent aller bien.

livenessProbe : ce processus est-il bloqué au point d'être irrécupérable ?

La liveness contrôle les redémarrages de conteneur. Quand elle échoue failureThreshold fois de suite, le kubelet tue le conteneur et le redémarre selon le restartPolicy du pod, avec un backoff exponentiel (CrashLoopBackOff quand ça se répète).

C'est un remède brutal, et c'est pourquoi la question à laquelle répond la liveness doit rester étroite : le processus est-il en deadlock, bloqué, ou incapable de progresser d'une façon que seul un redémarrage corrige ? Tout ce qui est moins grave relève de la readiness. Une probe de liveness ne devrait presque jamais échouer sur une flotte saine. Si la vôtre se déclenche régulièrement, soit l'application a un vrai défaut, soit la probe vérifie la mauvaise chose.

startupProbe : ce conteneur a-t-il fini de démarrer ?

La startup contrôle les deux autres probes. Tant qu'un startupProbe est défini et n'a pas encore réussi, le kubelet n'exécute ni la liveness ni la readiness. Dès qu'elle réussit une seule fois, elle ne tourne plus jamais et les autres probes prennent le relais.

Son but concerne les applications lentes à démarrer. Le temps de boot maximal accordé vaut failureThreshold × periodSeconds (plus initialDelaySeconds s'il est défini) ; si la probe n'a toujours pas réussi à ce moment-là, le conteneur est tué et redémarré. Ce budget vit à un seul endroit, sur une seule probe, au lieu d'être étalé sur l'initialDelaySeconds des deux autres.

Mécanique et paramètres des probes

Chaque probe utilise l'un des quatre handlers :

httpGet : le succès est un statut HTTP ≥ 200 et < 400. Le choix le plus courant pour les workloads web.
tcpSocket : le succès est l'établissement d'une connexion TCP. Prouve qu'un port est ouvert, rien sur l'application derrière.
exec : lance une commande dans le conteneur ; le code de sortie 0 est un succès. Souple, et le plus coûteux, puisque chaque exécution effectue un fork dans le conteneur.
grpc : utilise le gRPC Health Checking Protocol standard (GA depuis Kubernetes 1.27). La bonne réponse pour les serveurs gRPC, en remplacement de l'ancien contournement par exec grpc_health_probe.

Les paramètres de timing, avec leurs valeurs par défaut :

| Paramètre | Défaut | Signification | |---|---|---| | initialDelaySeconds | 0 | Attente avant le premier contrôle | | periodSeconds | 10 | Intervalle entre les contrôles | | timeoutSeconds | 1 | Temps alloué par contrôle | | failureThreshold | 3 | Échecs consécutifs avant d'agir | | successThreshold | 1 | Succès consécutifs pour récupérer (doit valoir 1 pour liveness et startup) |

Deux valeurs par défaut méritent l'attention. timeoutSeconds: 1 est agressif : une probe exec qui fork un shell, ou un handler HTTP qui touche quoi que ce soit de plus lent que la mémoire, peut faire sauter un budget d'une seconde sous charge, et un timeout de probe compte comme un échec. periodSeconds: 10 avec failureThreshold: 3 signifie que la détection prend jusqu'à 30 secondes, souvent plus lent que ce que les gens imaginent de la réactivité de leurs « health checks ».

Les modes de défaillance des probes copiées-collées

Voici les schémas qui transforment les probes d'un mécanisme de sécurité en amplificateur d'incident. Tous viennent de la copie d'un bloc qui a l'air de marcher sans se demander à quelle question il répond.

Liveness et readiness pointant sur le même endpoint

Le plus fréquent. Si /healthz échoue parce qu'une dépendance en aval est lente, la readiness sort correctement le pod de la rotation. La liveness, qui surveille le même endpoint, redémarre alors un processus qui n'a jamais été cassé. Multipliez par chaque réplica qui surveille la même dépendance lente, et vous obtenez une tempête de redémarrages coordonnés : la dépendance récupère, mais votre couche applicative est désormais en CrashLoopBackOff.

Les deux probes ont besoin d'endpoints différents parce qu'elles répondent à des questions différentes. /ready peut consulter tout ce dont l'application a besoin pour servir une requête ; /live ne devrait vérifier que le fait que le processus lui-même répond.

Contrôles de dépendances dans la probe de liveness

La version généralisée de l'erreur précédente. Un handler de liveness qui ping la base de données, interroge un broker de messages ou appelle un autre service convertit chaque hoquet de dépendance en un redémarrage massif des dépendants. Redémarrer vos pods d'API ne répare pas votre base de données ; cela ajoute du churn de connexions et des caches froids par-dessus le problème initial, et le fait sur chaque réplica à peu près au même moment.

La conscience des dépendances relève de la readiness, et même là avec précaution : si la readiness de chaque réplica échoue simultanément parce qu'une dépendance partagée est tombée, le Service se retrouve avec zéro endpoint et les clients reçoivent un connection refused au lieu d'une réponse dégradée. Pour une dépendance sans laquelle l'application pourrait fonctionner partiellement, renvoyer un 200 avec un comportement dégradé vaut souvent mieux que faire échouer la probe.

Aucun startupProbe sur une application lente à démarrer

Sans probe de startup, la liveness commence à vérifier après initialDelaySeconds. Pour une application au temps de boot variable (JVM qui chauffent, migrations qui tournent, gros caches à charger), cela impose un mauvais choix : soit régler initialDelaySeconds assez haut pour le pire cas, et encaisser ce délai à chaque redémarrage, même les rapides, soit le régler avec optimisme et regarder le kubelet tuer des conteneurs qui étaient à 5 secondes de la fin de leur boot. Le kill provoque un redémarrage, qui reboote lentement, qui se fait tuer à nouveau : une boucle de crash au démarrage entièrement causée par la configuration des probes.

Un startupProbe avec un failureThreshold généreux résout cela proprement :

startupProbe:
  httpGet:
    path: /live
    port: 8080
  periodSeconds: 5
  failureThreshold: 24      # up to 120 s to boot

L'application dispose de jusqu'à deux minutes pour se lever, contrôlée toutes les cinq secondes, si bien qu'un boot rapide est détecté rapidement. Une fois levée, la liveness tourne avec des réglages serrés de régime établi, plutôt que des réglages gonflés pour couvrir le démarrage.

Aucun readinessProbe du tout

Sans probe de readiness, un pod compte comme Ready dès que ses conteneurs tournent. Le trafic arrive avant que l'application n'écoute, et les rolling updates progressent sur la base de ce mensonge : les anciens pods sont tués parce que les nouveaux se déclarent « Ready ». Résultat, une salve d'erreurs à chaque déploiement qu'aucun réglage de liveness ne peut corriger.

tcpSocket là où httpGet était nécessaire

Une probe de readiness tcpSocket sur une application web prouve que le socket est ouvert. Une application peut accepter des connexions TCP bien avant que ses routes ne soient câblées, et bien après que sa boucle d'événements s'est bloquée. Si l'application parle HTTP, sondez-la en HTTP.

Un exemple complet

Les trois probes réunies, sur une application hypothétique au démarrage parfois lent :

containers:
  - name: app
    ports:
      - containerPort: 8080
    startupProbe:
      httpGet:
        path: /live
        port: 8080
      periodSeconds: 5
      failureThreshold: 24        # boot budget: 120 s
    readinessProbe:
      httpGet:
        path: /ready              # may check what serving requires
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 2         # out of rotation within ~10 s
    livenessProbe:
      httpGet:
        path: /live               # process responsive, nothing else
        port: 8080
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 3         # restart only after ~30 s of silence

Notez l'asymétrie : la readiness réagit plus vite que la liveness (failureThreshold: 2 contre 3, période plus courte). Être retiré du load balancing est peu coûteux et réversible ; un redémarrage n'est ni l'un ni l'autre. Vous voulez que le remède le moins cher se déclenche en premier.

Table de décision

| Question | Probe | En cas d'échec | L'endpoint devrait vérifier | |---|---|---|---| | Ce pod peut-il prendre du trafic maintenant ? | readinessProbe | Retiré des endpoints du Service | Application pleinement initialisée ; dépendances critiques, avec précaution | | Le processus est-il bloqué au point d'être irrécupérable ? | livenessProbe | Conteneur tué et redémarré | Réactivité du processus / de la boucle d'événements uniquement, jamais les dépendances | | Le conteneur a-t-il fini de démarrer ? | startupProbe | Conteneur tué et redémarré | Même handler que la liveness, failureThreshold généreux |

Et pour les paramètres :

| Situation | Réglage | |---|---| | Temps de boot variable ou > ~10 s | Ajouter un startupProbe ; garder initialDelaySeconds à 0 ailleurs | | Le handler fait un vrai travail (exec, disque, appel en aval) | Monter timeoutSeconds au-dessus du défaut d'1 s | | Le trafic doit quitter vite un pod défaillant | Baisser le produit periodSeconds × failureThreshold de la readiness | | Les redémarrages coûtent cher (caches, connexions) | Monter le failureThreshold de la liveness ; rendre le handler trivial | | Serveur gRPC | Utiliser le handler grpc, pas un contournement par exec |

Ce que les probes ne résolvent pas

Deux limites qu'il vaut la peine de connaître. D'abord, un readinessProbe correct ne vous donne pas des déploiements sans interruption : la terminaison d'un pod pendant un rollout est une course de propagation que la readiness ne peut pas influencer, et la corriger passe par les hooks preStop et la gestion de SIGTERM. Les rouages sont résumés dans l'entrée de glossaire sur les rolling deployments. Ensuite, les probes continuent de fonctionner sous une NetworkPolicy default-deny : le kubelet sonde les pods depuis le nœud lui-même et les CNI exemptent ce trafic host-local, un détail qui compte quand on déploie une NetworkPolicy default-deny.

Le modèle mental qui survit au contact de la production est simple : la readiness est une décision de routage, la liveness une décision de redémarrage, la startup un budget de temps de démarrage. Configurez chacune pour ne répondre qu'à sa propre question, donnez au remède le moins cher un déclenchement plus rapide qu'au remède brutal, et lisez les valeurs par défaut avant de leur faire confiance. Régler les probes pour qu'elles répondent honnêtement est une petite pièce d'une discipline plus large, amener une plateforme à signaler ses propres pannes avant que les utilisateurs ne les voient, ce qui est l'objet de mon offre fiabilité et observabilité. Plus de contenu Kubernetes dans la catégorie kubernetes.

Instrumenting an app for Prometheus: golden signals

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "instrument application prometheus", "golden signals", "prometheus histogram vs summary", "histogram_quantile" are global technical queries searched almost exclusively in English. Reference tutorial for the international SRE/platform audience, consistent with the strategy of publishing pointed technical material in English. Foundation article beneath the already-published alerting piece: it produces the metrics that symptom-based alerts consume.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against documented Prometheus behavior (metric types, histogram_quantile, exposition format). No production anecdotes by design; this is not a REX. -->

Your cluster is covered in metrics. node_exporter reports CPU, RAM and disk usage, kube-state-metrics knows the state of every pod. Then a product manager asks "is checkout slower than this morning?", and nobody can answer. All of those metrics describe the machines and the orchestrator; none of them describe what your application does. That is exactly the gap instrumentation fills: exposing, from the code, the few numbers that say whether the service is serving.

The four signals, and where to start

The most useful grid is still the golden signals from Google's SRE book: latency (how long a request takes), traffic (how much you get), errors (how much fails), and saturation (how loaded your resources are). Saturation is already well covered by node_exporter and cluster metrics. That leaves three things to instrument in the application itself, which the RED method captures neatly for anything that answers requests: Rate, Errors, Duration.

In other words, before adding a single business metric, expose how many requests arrive, how many go wrong, and how long they take. Everything else is diagnosis you reach for once one of those three signals has paged you.

The right metric type for the question

Prometheus has four metric types, and the choice is not cosmetic. A counter only ever goes up and is read with rate(): it is the type for traffic and errors, an http_requests_total carrying a status label. A gauge is an instantaneous value that goes up and down, for anything counted at a point in time (in-flight connections, queue depth). A histogram samples a distribution into predefined buckets, and it is the right tool for latency. A summary looks similar but computes its quantiles differently, with a heavy consequence covered below.

An instrumented handler, and the queries to match

Concretely, your client library exposes a text format like this at scrape time:

# TYPE http_requests_total counter
http_requests_total{service="checkout",status="200"} 128934
http_requests_total{service="checkout",status="500"} 271

# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{service="checkout",le="0.1"} 24054
http_request_duration_seconds_bucket{service="checkout",le="0.3"} 33444
http_request_duration_seconds_bucket{service="checkout",le="1"}   34101
http_request_duration_seconds_bucket{service="checkout",le="+Inf"} 34115
http_request_duration_seconds_sum{service="checkout"}   5342.7
http_request_duration_seconds_count{service="checkout"} 34115

The histogram exposes cumulative counters per le (less than or equal) boundary, plus a _sum and a _count. From there, two queries cover most of the ground:

# error rate per service
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  /
sum(rate(http_requests_total[5m])) by (service)

# p99 latency per service
histogram_quantile(
  0.99,
  sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
)

These are precisely the metrics that symptom-based Prometheus alerts consume: instrument first, alert second. A rule watching error rate or latency only exists because the application was instrumented to expose them.

Histogram or summary: why the quantile is computed server-side

Here is the distinction that decides the type. A summary computes its quantiles in the client, per instance, and publishes a ready-made quantile="0.99". The catch: you cannot sum or average quantiles. The p99 of ten pods is not the mean of their ten p99s. The moment your service runs in more than one replica, a summary hands you ten numbers that cannot be recombined into one service latency.

A histogram does the opposite: it exposes raw per-bucket counts, and histogram_quantile() reconstructs the quantile server-side, after you aggregate the buckets with sum by (le). Since everything runs in multiple copies on Kubernetes, the histogram is the default. Its cost: you have to choose the buckets up front.

Buckets, interpolation, and the pitfalls

histogram_quantile() interpolates linearly within the bucket where the quantile lands. The precision of your p99 is therefore the width of the bucket around it. The default buckets (a few milliseconds to ten seconds) rarely bracket a real target, so place the boundaries where you make decisions. If your target is 300ms, you want boundaries near 0.25, 0.3, 0.5. And if the quantile falls in the +Inf bucket, the result stops being a value and becomes a lower bound, a sign your buckets are too coarse. Native histograms, a newer option, remove this bucket choice at the price of still-experimental status.

Three other traps recur. Cardinality first: a label per user, per raw URL, or per request ID multiplies your series by the number of buckets and blows up storage cost, a subject the glossary entry on metric cardinality covers. Keep labels bounded: route template, not raw path; status class, not full message. Averaging quantiles second, an avg of a p99, which means nothing: aggregate the buckets, never the quantiles. Too few buckets around the target last, which makes the p99 unreadable at the exact moment it matters.

What to keep

Instrument three things from the code, traffic, errors and duration, and leave saturation to node_exporter. A counter for rates, a histogram for latency, with its boundaries placed around the decision you actually make. Prefer histograms to summaries the moment the service runs in more than one replica, and keep label cardinality bounded, because an instrumented app that costs more than it observes is its own kind of outage. This kind of useful observability is the foundation of my reliability and observability work; more in the observability category.

Alertes Prometheus actionnables : symptômes, pas les causes

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=fr justification : cible les requêtes FR "alerting prometheus", "alerte symptome ou cause", "clause for prometheus", et sert de relais LinkedIn francophone. Le pendant EN vise la longue traîne mondiale (même translationKey).

Note contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre le comportement documenté de Prometheus et Alertmanager. Aucune anecdote de production par construction ; ce n'est pas un REX. -->

3h du matin, le pager se déclenche : HighCPUUsage, nœud à 92 %. Vous ouvrez un laptop, vous regardez, tout fonctionne. Les utilisateurs dorment, le batch qui a fait grimper le CPU s'est terminé tout seul, et vous retournez vous coucher agacé. Deux semaines de ce régime et l'équipe coupe le son du canal d'alertes. La règle était techniquement correcte et totalement inutile, parce qu'elle signalait une cause qui n'a pas forcément de conséquence visible.

L'idée la plus utile en alerting tient en une phrase : on réveille un humain sur un symptôme, et on laisse les causes sur les tableaux de bord. Un CPU élevé n'est pas un problème. Des réponses lentes en sont un. Si le CPU est à 92 % et que le service tient toujours sa cible de latence, il n'y a rien à faire. En alertant sur ce que les utilisateurs ressentent réellement, on obtient un pager qui veut dire « quelque chose est cassé maintenant » au lieu de « un chiffre a franchi un seuil ».

Alerte sur symptôme contre alerte sur cause

Une règle par cause surveille une ressource interne : CPU, mémoire, profondeur de file, remplissage disque. Une règle par symptôme surveille le contrat avec l'utilisateur : taux d'erreur, latence, disponibilité. Le défaut de l'alerte par cause, c'est que la correspondance entre cause et symptôme n'est pas bijective. Un CPU saturé fait mal parfois, et le plus souvent non. Un disque plein est une vraie urgence sur un nœud de base de données, un haussement d'épaules sur un réplica sans état. Chaque cause exige qu'un humain tranche pour savoir si elle compte, à 3h du matin, ce qui est précisément la décision que l'alerte était censée prendre à votre place.

Il ne s'agit pas de supprimer vos métriques de ressources. Gardez-les : c'est avec elles que vous diagnostiquez un incident une fois qu'une alerte de symptôme vous a réveillé. La règle de pouce tient en trois mots : les symptômes réveillent, les causes renseignent. Le disque qui se remplit et le certificat qui expire sont les exceptions honnêtes, parce que ce sont des causes dont le symptôme futur est garanti et prévisible ; alerter en avance est justement tout l'intérêt.

Ce que font vraiment `for` et le label de sévérité

Prometheus évalue les règles d'alerte à chaque evaluation_interval (1 minute par défaut). Quand l'expression d'une règle renvoie des séries, les alertes correspondantes passent à l'état pending. Elles ne deviennent firing, et ne sont transmises à Alertmanager, qu'une fois l'expression restée vraie sans interruption pendant la durée du champ for. Une seule évaluation où l'expression ne renvoie rien remet le compteur à zéro.

Cette clause for est votre premier filtre anti-bruit, et le moins cher. Une expression sans for se déclenche sur un seul scrape : un scrape lent isolé ou un pic transitoire suffit à vous notifier. for: 10m signifie « je ne m'y intéresse que si c'est encore vrai dans dix minutes », ce qui écarte exactement les micro-incidents auto-résolus à l'origine des fausses alertes nocturnes. La contrepartie est un délai de détection, alors ajustez-le par symptôme : un service franchement à terre justifie un for: 2m, une latence qui dérive lentement un for: 15m.

La sévérité est un simple label, pas une fonctionnalité intégrée. La convention retient severity: critical pour « réveiller quelqu'un » et severity: warning pour « à regarder en heures ouvrées ». Le label ne veut rien dire pour Prometheus lui-même ; il devient utile dans le routage Alertmanager, où l'on envoie critical vers le pager et warning vers un canal de discussion. Bien poser ce partage, c'est l'essentiel de ce qui sépare une astreinte sereine d'une astreinte épuisée. Si tout est critique, plus rien ne l'est.

Une mauvaise règle réécrite en bonne règle

Voici une règle qui a l'air raisonnable et qui notifie sans arrêt :

groups:
  - name: bad.rules
    rules:
      - alert: HighCPUUsage
        expr: rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.8
        labels:
          severity: critical
        annotations:
          summary: "CPU élevé"

Tout y invite à la fatigue. Elle se déclenche par cœur et non par nœud, n'a pas de for donc un pic isolé notifie, qualifie un chiffre de consommation de critical, et son annotation ne dit rien d'exploitable au répondant. Réécrite autour d'un symptôme :

groups:
  - name: good.rules
    rules:
      - alert: HighRequestErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
            /
          sum(rate(http_requests_total[5m])) by (service)
            > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.service }} sert plus de 5 % d'erreurs"
          description: "Ratio d'erreurs 5xx à {{ $value | humanizePercentage }} sur 5m. Vérifier les déploiements récents et les dépendances en aval."
          runbook_url: "https://runbooks.internal/high-error-rate"

La bonne règle alerte sur ce que vit un utilisateur (une requête en échec), agrège à une unité qui a du sens (par service), survit à un pic transitoire (for: 10m) et fournit au répondant un point de départ via ses annotations et un lien de runbook. Décider où placer ce seuil de 5 % relève d'un error budget et d'un objectif de niveau de service défini, pas d'un nombre inventé au clavier. Et cette règle suppose que les bonnes métriques existent déjà : le taux d'erreur et la latence qu'on interroge ici viennent d'une application instrumentée pour les exposer, un préalable détaillé dans instrumenter une application avec Prometheus.

Les pièges qui résistent aux bonnes intentions

Trois pièges reviennent même dans un dispositif orienté symptômes. La division par zéro d'abord : un ratio comme celui ci-dessus ne renvoie rien quand un service ne reçoit aucun trafic, si bien qu'une panne stoppant toutes les requêtes peut faire taire l'alerte censée la détecter. Doublez les alertes de taux d'erreur d'un contrôle de trafic faible ou d'absence. Les seuils trop zélés sans notion de burn rate ensuite : un « 5 % pendant 10m » figé rate une combustion lente qui grignote le budget du mois et hurle sur un pic bref, d'où l'existence de l'alerting multi-fenêtre multi-burn-rate. L'inflation de critical enfin : chaque alerte ajoutée en critique parce qu'elle « semblait importante » entraîne l'astreinte à ignorer le pager, et un pager qu'on ignore est pire que pas de pager.

À retenir

Alertez sur les symptômes, gardez les causes pour le diagnostic. Servez-vous de for pour filtrer le bruit auto-résolu, et réservez critical à ce qui mérite vraiment de sortir un humain du lit. Rédigez les annotations pour la personne fatiguée qui les lit à 3h, pas pour vous qui les écrivez à 15h. Un dispositif d'alerte construit ainsi est un livrable central d'une mission fiabilité et observabilité. D'autres sujets dans la catégorie observabilité, et la même discipline appliquée aux sondes se trouve dans readiness et liveness sur Kubernetes.

Requests et limits Kubernetes : throttling, OOMKill et QoS

Fri, 24 Jul 2026 00:00:00 GMT

<!-- justification lang=fr : version française de l'article EN "kubernetes-resource-requests-limits". Le contenu est un tutoriel de référence générique ; la version FR sert le public francophone (relais LinkedIn FR) et le maillage interne vers le glossaire et les offres. Paire liée via translationKey.

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre la documentation Kubernetes, le comportement des cgroups et les métriques cAdvisor. Aucune anecdote de production par construction, ce n'est pas un REX. -->

Un pod tourne sans histoire, puis disparaît avec OOMKilled et le code de sortie 137. Un autre rame sous charge alors que le nœud qui l'héberge est inoccupé à 70 %. Les deux symptômes remontent aux mêmes deux champs que la plupart des manifests renseignent par réflexe et que peu de gens lisent vraiment : requests et limits. Ce ne sont pas deux réglages du même curseur. Ils agissent à des moments différents, sur des sous-systèmes différents, avec des conséquences opposées quand on les franchit.

Requests et limits ne font pas le même travail

Une request est une donnée d'ordonnancement. Le scheduler place les pods en additionnant leurs requests par rapport à la capacité allouable d'un nœud ; une request est une réservation, le plancher que le pod est certain d'obtenir. Elle ne plafonne jamais l'usage.

Une limit est un plafond d'exécution imposé par le kubelet et le noyau via les cgroups. Ce qui arrive quand un conteneur touche ce plafond dépend entièrement de la ressource concernée, car le CPU et la mémoire se comportent à l'inverse l'un de l'autre.

Franchir la limite CPU : le throttling

Le CPU est une ressource compressible. Le noyau peut accorder moins de cycles à un processus sans le tuer.

La request CPU devient un poids cgroup (cpu.shares en cgroup v1, cpu.weight en v2, où un cœur vaut 1024 shares). Ce poids ne compte qu'en cas de contention : il décide comment des processus affamés se partagent un CPU saturé. Tant que le nœud a de la marge, tout le monde s'exécute librement, requests ou pas.

La limit CPU devient du CFS bandwidth control : un quota par période d'ordonnancement (cpu.cfs_quota_us / cpu.cfs_period_us, ou cpu.max en v2), avec une période de 100 ms par défaut. Une limite à 500m accorde 50 ms de CPU par fenêtre de 100 ms. Épuisez ce budget avant la fin de la fenêtre et le conteneur est throttlé, mis en pause jusqu'à la période suivante. Pas de kill, juste de la latence.

Le piège tient à cette application par période. Le throttling se déclenche que le nœud soit chargé ou non, si bien qu'une charge en pics et sensible à la latence peut être fortement throttlée pendant que la machine reste largement inoccupée. Surveillez le rapport entre container_cpu_cfs_throttled_periods_total et container_cpu_cfs_periods_total : une valeur élevée, c'est du throttling CFS, pas une application lente.

Franchir la limite mémoire : l'OOMKill

La mémoire est incompressible. On ne peut pas demander à un processus de détenir moins de RAM comme on lui donne moins de cycles.

La request mémoire alimente l'ordonnancement et le classement d'éviction ; ce n'est pas un plafond. La limit mémoire, elle, est un plafond dur (memory.max / memory.limit_in_bytes). Touchez un octet au-delà et l'OOM killer du cgroup envoie un SIGKILL à un processus du groupe. Kubernetes marque le conteneur OOMKilled, code de sortie 137 (128 + SIGKILL), le redémarre selon le restartPolicy, et tombe en CrashLoopBackOff si cela se répète.

Deux événements mémoire distincts prêtent à confusion. Atteindre la limite de son propre conteneur, c'est un OOMKill de cgroup : niveau noyau, immédiat, cantonné au pod. Le nœud globalement à court de mémoire déclenche plutôt une éviction par le kubelet, qui trie ses victimes selon la classe QoS et la distance de chaque pod au-dessus de sa request.

Les classes QoS se déduisent, elles ne se déclarent pas

Kubernetes attribue une classe à chaque pod à partir de ce que vous avez posé :

Guaranteed : chaque conteneur fixe requests == limits pour le CPU et la mémoire. Il reçoit un oom_score_adj fortement négatif (-997) et est évincé en dernier.
Burstable : au moins une request ou une limit est posée, sans atteindre Guaranteed.
BestEffort : rien du tout. Il obtient un oom_score_adj de 1000, et c'est le premier évincé comme le premier que le noyau tue sous pression mémoire.

La classe n'est pas cosmétique : sous pression, elle décide qui meurt d'abord, et cet ordre justifie à lui seul de poser ses requests honnêtement.

Le débat des limites CPU

C'est un vrai sujet, toujours vivant. L'argument pour retirer les limites CPU : le throttling CFS coûte de la latence même sur un nœud inoccupé, et une request CPU garantit déjà une part proportionnelle en cas de contention, donc une limite ne fait souvent qu'acheter du throttling inutile. L'argument pour les garder : une planification de capacité prévisible, une protection contre un voisin qui s'emballe, et le fait que les limites CPU sont requises pour la classe Guaranteed et pour le pinning CPU statique.

Le compromis sur lequel atterrissent la plupart des équipes plateforme : poser presque toujours request == limit en mémoire (ressource incompressible, on veut un plafond dur et prévisible), toujours poser une request CPU, et traiter les limites CPU comme optionnelles, appliquées seulement là où une règle précise l'exige.

Une méthode pour régler les défauts

Mesurer, ne pas deviner. Utilisez le Vertical Pod Autoscaler en mode recommandation (updateMode: "Off") ou interrogez directement l'historique Prometheus. Le même réflexe de mesure que pour un SLO s'applique ici : on règle ce qu'on a observé, jamais ce qu'on imagine.

# pic de working set mémoire sur 7 jours, par pod
max_over_time(container_memory_working_set_bytes{container="app"}[7d])

# 95e centile de cœurs CPU consommés sur 7 jours
quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container="app"}[5m])[7d:5m])

On dérive ensuite les valeurs de ces chiffres :

resources:
  requests:
    cpu: 250m           # usage typique, pilote l'ordonnancement
    memory: 512Mi
  limits:
    memory: 512Mi       # égale à la request : plafond dur et prévisible
    # pas de limite CPU : peut déborder sur la capacité libre, garde 250m sous contention

Mémoire request == limit, calée sur le pic de working set observé plus 20 à 30 % de marge. Request CPU à l'usage typique (autour du P90), limite CPU laissée de côté sauf règle contraire. On remesure une fois le vrai trafic arrivé : les premiers chiffres sont une hypothèse, pas un verdict.

Pièges classiques

Ne poser qu'une limit fait recopier cette valeur dans la request, ce qui peut sur-réserver le nœud en silence. Reprendre les chiffres d'une autre équipe ignore que les requests sont propres à la charge : trop hautes elles gâchent des nœuds, trop basses elles invitent l'éviction. Dimensionner la mémoire sur le RSS plutôt que sur le working set oublie le page cache que le noyau compte dans votre limite. Accuser l'application d'une latence qui n'est que du throttling CFS fait perdre des journées : vérifiez le rapport de throttling avant de profiler du code.

À retenir

Les requests sont pour le scheduler, les limits pour le noyau. Au-delà de la limite CPU on est throttlé, au-delà de la limite mémoire on est tué. Posez la mémoire request == limit, posez une request CPU, soyez délibéré sur les limites CPU, et tirez chaque chiffre d'un usage mesuré plutôt que d'un template. Un redémarrage dû à un OOMKill et un redémarrage dû à un liveness probe qui échoue sont indiscernables dans kubectl describe, d'où l'intérêt de savoir comment se comportent vraiment les probes avant de déboguer la mauvaise. Bien dimensionner ces ressources sur tout un parc fait une bonne partie du travail qui rend une migration vers Kubernetes durable en production, et c'est le cœur de mon offre migration d'infrastructure legacy vers Kubernetes. Plus de contenu Kubernetes dans la catégorie kubernetes.

Kubernetes : Secrets natifs, Sealed Secrets ou Vault ?

Fri, 24 Jul 2026 00:00:00 GMT

<!-- Justification lang=fr : version française d'un tutoriel de référence générique, alignée sur l'amendement §2.4 (i18n systématique pour le contenu factuel générique). L'original EN vise la longue traîne technique mondiale ; cette version couvre les requêtes francophones ("secrets kubernetes chiffrement", "sealed secrets vault") et relaie sur LinkedIn FR.

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout face à la documentation Kubernetes, Sealed Secrets et Vault. Aucune anecdote de production par construction, ce n'est pas un REX. -->

kubectl get secret app-db -o yaml renvoie un bloc data rempli de chaînes illisibles. Ça ressemble à du chiffré. Ça n'en est pas. Les valeurs d'un Secret Kubernetes sont encodées en base64, et le base64 est un encodage de transport que n'importe qui inverse en une commande :

kubectl get secret app-db -o jsonpath='{.data.password}' | base64 -d

Ce seul fait commande toutes les décisions qui suivent. Un Secret natif ne protège rien en lui-même. Ce qui le garde vraiment, c'est le RBAC (qui a le droit de faire get sur l'objet) et, au repos, le fait qu'etcd soit chiffré ou non.

Ce qu'un Secret natif protège, et ce qu'il ne protège pas

Par défaut, etcd stocke les objets Secret sans chiffrement. Le chiffrement au repos s'active explicitement, via une EncryptionConfiguration sur l'API server :

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <clé base64 de 32 octets>
      - identity: {}

Sans cette configuration, une sauvegarde d'etcd est une sauvegarde de tous vos credentials en clair (en base64). Avec elle, la valeur est chiffrée dans le datastore mais reste du base64 pour quiconque dispose d'un accès en lecture à l'API. Deux modèles de menace distincts, et les Secrets natifs ne couvrent le premier qu'une fois que vous l'avez délibérément activé.

Le problème que les Secrets natifs ne résolvent jamais, c'est Git. On ne commit pas un manifeste Secret en clair dans un dépôt. C'est dans cette faille que vivent les deux autres approches.

Sealed Secrets : rendre le manifeste committable

Sealed Secrets (le contrôleur de Bitnami) ajoute une CRD et un contrôleur dans le cluster qui détient une paire de clés asymétriques. On chiffre avec le certificat public grâce à kubeseal, et seule la clé privée du contrôleur peut déchiffrer :

kubectl create secret generic app-db \
  --from-literal=password='s3cr3t' --dry-run=client -o yaml \
  | kubeseal --format yaml > sealed-app-db.yaml

Le SealedSecret obtenu vit sans risque dans Git. Le contrôleur le détecte, le déchiffre et matérialise un Secret ordinaire dans le namespace. Votre pipeline GitOps décrit désormais les secrets comme il décrit tout le reste.

Deux propriétés dessinent les limites. Le scellage est lié au cluster : un SealedSecret est chiffré pour la clé d'un contrôleur donné, donc restaurer les manifestes dans un cluster neuf échoue tant que vous n'avez pas sauvegardé puis restauré la clé de scellage (elle-même un Secret dans kube-system). Perdre cette clé rend irrécupérable chaque SealedSecret présent dans Git. Le scope par défaut est également strict : le chiffré est lié au couple exact name plus namespace, et on ne peut ni renommer ni déplacer un SealedSecret sans le resceller.

Sealed Secrets stocke des valeurs chiffrées. Il ne les fait pas tourner, ne les expire pas, ne trace pas qui les lit. Faire tourner un mot de passe reste un commit.

Vault : secrets dynamiques, leasing, audit

Vault en externe change le modèle. Plutôt que de stocker un credential statique, Vault peut en générer un à la demande et le remettre avec un lease :

vault write database/roles/app-db \
  db_name=app-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';" \
  default_ttl="1h" max_ttl="24h"

Une application s'authentifie (l'auth Kubernetes échange le token de ServiceAccount d'un pod contre un token Vault), lit database/creds/app-db et récupère un utilisateur Postgres neuf, valide une heure. À l'expiration du lease, Vault révoque le credential à la source. Un credential fuité a alors un rayon d'action qui se compte en minutes, et chaque lecture atterrit dans un journal d'audit.

Tirer ces valeurs jusque dans les pods se fait en général avec l'External Secrets Operator ou le Vault Secrets Operator, qui synchronisent un chemin Vault vers un Secret natif consommé normalement par les workloads.

Le coût est opérationnel et bien réel : un Vault en haute dispo, c'est un stockage Raft sur trois nœuds ou plus, une stratégie d'unseal (auto-unseal via un KMS cloud, ou des porteurs humains de parts de clé Shamir), des sauvegardes testées et une cadence de montée de version à tenir. Depuis le passage de Vault sous licence BSL, OpenBao est le fork open source à mettre dans la balance.

Les pièges classiques

Prendre le base64 pour une frontière de sécurité. L'erreur la plus fréquente, et de loin. Restreignez le RBAC, activez le chiffrement au repos, et ne lisez jamais data: comme une protection.
Ne pas sauvegarder la clé de Sealed Secrets. On commit les SealedSecrets, on se sent en sécurité, puis on découvre après une reconstruction de cluster que Git seul ne les restaure pas.
Déployer Vault pour des secrets statiques. Si rien de ce que vous stockez n'est dynamique et que vous ne touchez jamais au leasing ni à l'audit, vous avez pris en charge la contrainte d'exploitation d'un système distribué pour faire ce qu'un seul contrôleur Sealed Secrets fait déjà.
Oublier qu'un Secret est référencé par son nom. Faire un rollback d'un Deployment ne fait pas de rollback du Secret qu'il pointe.

Comment trancher

La taille de l'équipe et l'exigence de conformité tracent la ligne :

Petite équipe, pas de store externe, GitOps déjà en place : Secrets natifs avec chiffrement au repos, plus Sealed Secrets pour que le dépôt soit la source de vérité. Coût d'exploitation minimal, et ça couvre la plupart des PME.
Secrets statiques, un fournisseur cloud disponible : un secret manager managé derrière External Secrets Operator déplace la séparation des environnements dans l'IAM, exactement là où on la veut. C'est la même logique que celle du service discovery : ne pas coder en dur ce qui doit rester découvrable et révocable.
Credentials dynamiques, vraies exigences d'audit ou de rotation, parc hétérogène (VMs plus Kubernetes plus CI) : Vault gagne sa place, mais seulement si vous pouvez nommer aujourd'hui la personne qui le mettra à jour dans dix-huit mois.

À retenir

Les Secrets natifs sont du base64, pas du chiffrement ; ce sont le RBAC et le chiffrement d'etcd au repos qui les protègent réellement. Sealed Secrets rend un manifeste committable et s'insère dans un dépôt GitOps, au prix d'une clé liée au cluster qu'il ne faut jamais perdre. Vault achète des secrets dynamiques, du leasing et de l'audit, au prix d'un système distribué à état à opérer. Calez l'outil sur un fait que vous pouvez désigner (une clause de conformité, une obligation de rotation, un parc hybride), pas sur une intention. Ces arbitrages font partie du travail que je mène dans mon offre industrialisation du CI/CD.

Kubernetes Secrets: Plain Secrets, Sealed Secrets, or Vault?

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "kubernetes secrets encryption", "sealed secrets vs vault" and "base64 secret decode" are global technical queries typed almost exclusively in English by engineers evaluating a secrets strategy. Fits the strategy of publishing reference tutorials in English for the worldwide long tail.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against Kubernetes, Sealed Secrets and Vault documented behavior. No production anecdotes by design, this is not a REX. -->

kubectl get secret app-db -o yaml returns a data block full of unreadable strings. It looks encrypted. It is not. Kubernetes Secret values are base64-encoded, and base64 is a transport encoding anyone can reverse in a single command:

kubectl get secret app-db -o jsonpath='{.data.password}' | base64 -d

That one fact drives every decision below. A native Secret protects nothing on its own. What actually guards it is RBAC (who is allowed to get the object) and, at rest, whether etcd itself is encrypted.

What native Secrets do and do not protect

By default, etcd stores Secret objects without encryption. Encryption at rest is opt-in, configured with an EncryptionConfiguration on the API server:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <32-byte base64 key>
      - identity: {}

Without it, an etcd backup is a backup of every credential in plaintext (base64). With it, the value is encrypted in the datastore but still plain base64 to anyone holding API read access. Those are two different threat models, and native Secrets address the first one only once you deliberately turn it on.

The problem native Secrets never solve is Git. You cannot commit a plaintext Secret manifest to a repository. That gap is where the other two approaches live.

Sealed Secrets: make the manifest safe to commit

Sealed Secrets (the Bitnami controller) adds a CRD and an in-cluster controller holding an asymmetric key pair. You encrypt with the public certificate using kubeseal, and only the controller's private key can decrypt:

kubectl create secret generic app-db \
  --from-literal=password='s3cr3t' --dry-run=client -o yaml \
  | kubeseal --format yaml > sealed-app-db.yaml

The resulting SealedSecret is safe in Git. The controller watches for it, decrypts it, and materialises an ordinary Secret in the namespace. Your GitOps pipeline now describes secrets the same way it describes everything else.

Two properties define the boundaries. Sealing is cluster-bound: a SealedSecret is encrypted for one controller's key, so restoring manifests into a fresh cluster fails until you have backed up and restored the sealing key (itself a Secret in kube-system). Lose that key and every SealedSecret in Git becomes unrecoverable. The default scope is also strict, meaning the ciphertext is bound to the exact name plus namespace; you cannot rename or move a SealedSecret without re-sealing it.

Sealed Secrets stores encrypted values. It does not rotate them, expire them, or record who reads them. Rotating a password stays an edit-and-commit.

Vault: dynamic secrets, leasing, audit

External Vault changes the model. Rather than storing a static credential, Vault can generate one on demand and hand it back with a lease:

vault write database/roles/app-db \
  db_name=app-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';" \
  default_ttl="1h" max_ttl="24h"

An application authenticates (Kubernetes auth exchanges a pod's ServiceAccount token for a Vault token), reads database/creds/app-db, and receives a fresh Postgres user valid for one hour. When the lease expires, Vault revokes the credential at the source. A leaked credential then has a blast radius measured in minutes, and every read lands in an audit log.

Pulling those values into pods is usually done through the External Secrets Operator or the Vault Secrets Operator, which sync a Vault path into a native Secret so workloads consume it the normal way.

The cost is operational and concrete: an HA Vault means Raft storage across three or more nodes, an unseal strategy (auto-unseal via a cloud KMS, or human holders of Shamir key shares), tested backups, and an upgrade cadence to follow. Since Vault moved to the BSL license, OpenBao is the open-source fork worth putting on the table.

Common traps

Treating base64 as a security boundary. The single most frequent mistake. Restrict RBAC and enable encryption at rest; never read data: as protection.
Not backing up the Sealed Secrets key. Teams commit SealedSecrets, feel safe, then discover after a cluster rebuild that Git alone cannot restore them.
Deploying Vault for static secrets. If nothing you store is dynamic and you never touch leasing or audit, you have taken on a distributed system's operational burden to do what one Sealed Secrets controller already does.
Forgetting that a Secret is referenced by name. Rolling back a Deployment does not roll back the Secret it points to.

How to choose

Team size and compliance requirements draw the line:

Small team, no external store, GitOps already in place: native Secrets with encryption at rest, plus Sealed Secrets so the repository is the source of truth. Lowest operational cost, and it covers most small and mid-size shops.
Static secrets, a cloud provider available: a managed secret store behind External Secrets Operator moves separation of environments into IAM, which is exactly where it belongs.
Dynamic credentials, real audit or rotation mandates, a mixed estate (VMs plus Kubernetes plus CI): Vault earns its keep, but only when you can name today the person who will patch it in eighteen months.

Takeaways

Native Secrets are base64, not encryption; RBAC and etcd encryption at rest are what actually protect them. Sealed Secrets make a manifest safe to commit and fit a GitOps repository, at the price of one cluster-bound key you must never lose. Vault buys dynamic secrets, leasing and audit, at the price of running a stateful distributed system. Match the tool to a fact you can point at (a compliance clause, a rotation mandate, a hybrid estate), not to an aspiration. More material in the automatisation category, and this kind of arbitration is part of industrialising your CI/CD.

State Terraform distant et verrouillage : comment ça marche

Fri, 24 Jul 2026 00:00:00 GMT

<!-- Justification lang=fr : cet article couvre la requête « terraform state verrouillage » et « backend distant terraform » côté francophone, où la concurrence SEO est faible face au contenu anglais. Il alimente aussi le relais LinkedIn FR vers l'offre industrialisation CI/CD. La version EN existe pour la longue traîne technique mondiale (translationKey partagé).

Note de contenu (directive JM 2026-07-24) : tutoriel de référence, générique et vérifiable de bout en bout contre la documentation Terraform et le comportement des backends. Aucune anecdote de production par choix, ce n'est pas un REX. -->

Deux ingénieurs lancent terraform apply sur la même stack à quelques secondes d'intervalle. Les deux lisent le state, les deux planifient dessus, les deux le réécrivent. La seconde écriture écrase la première en silence, et le state décrit désormais une infrastructure qui ne correspond plus au réel. Personne n'a vu passer d'erreur. C'est précisément le scénario contre lequel le state local n'a jamais été conçu pour protéger, et la raison d'être des backends distants.

Pourquoi le state local ne tient pas en équipe

Terraform conserve un fichier de state qui associe chaque ressource de votre configuration à un objet réel chez votre fournisseur, avec les métadonnées et l'ordre des dépendances. Par défaut, ce fichier est terraform.tfstate, posé sur le poste de la dernière personne à avoir lancé un apply.

Ce défaut lâche dès qu'une deuxième personne arrive :

Il n'est pas partagé. Le state de votre collègue ignore les ressources que vous avez créées. Son prochain plan veut les recréer.
Il n'a aucun verrou. Rien n'empêche deux apply de tourner en même temps, et le cycle lecture-modification-écriture de Terraform n'est pas atomique entre deux machines.
Il expose des secrets. Le state stocke les attributs des ressources en clair, y compris les mots de passe et clés générés, désormais éparpillés sur des postes et parfois dans Git.

Un backend distant règle les trois d'un coup : une copie qui fait autorité, un stockage à accès contrôlé, et un mécanisme de verrouillage.

Ce qu'apporte un backend distant

Le backend se déclare dans le bloc terraform. Le backend S3 sert de référence courante :

terraform {
  backend "s3" {
    bucket       = "acme-tfstate"
    key          = "platform/prod/terraform.tfstate"
    region       = "eu-west-1"
    encrypt      = true
    use_lockfile = true   # verrouillage S3 natif, Terraform 1.10+
  }
}

Le state vit maintenant dans S3, versionné et chiffré, et le verrou est géré par un fichier de lock écrit à côté, via les écritures conditionnelles de S3. Historiquement ce verrou reposait sur une table DynamoDB dédiée (clé primaire LockID) ; cette approche fonctionne toujours, mais le lock file natif a supprimé cette dépendance supplémentaire pour les nouvelles stacks.

Les autres backends déclinent la même idée autrement. Le backend GCS intègre le verrouillage nativement, à partir des numéros de génération d'objet, sans table annexe. HCP Terraform (ex-Terraform Cloud) prend en charge le stockage du state et le verrou pour vous, et ajoute par-dessus l'historique des runs et les politiques d'accès.

Comment le verrou fonctionne réellement

Avant toute opération susceptible d'écrire le state (apply, et plan quand il rafraîchit), Terraform acquiert un verrou. Ce verrou est un petit enregistrement qui retient qui l'a pris, pour quelle opération, quand, et sous quel identifiant. Tant qu'il est détenu, un second run refuse de démarrer :

$ terraform apply
╷
│ Error: Error acquiring the state lock
│
│ Lock Info:
│   ID:        a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d
│   Operation: OperationTypeApply
│   Who:       alice@build-runner-07
│   Created:   2026-07-24 09:14:22 UTC
╵

C'est le système qui fait exactement son travail. Le verrou est relâché automatiquement à la fin de l'opération, qu'elle réussisse ou qu'elle échoue proprement.

Le piège classique : le verrou fantôme

Le verrou n'est relâché proprement que si Terraform va jusqu'au bout de sa libération. Coupez le processus avec deux Ctrl-C, perdez le réseau en plein apply, ou faites évincer un runner de CI, et le verrou reste détenu sans propriétaire derrière. Chaque run suivant échoue alors sur le même Error acquiring the state lock, ce qui bloque toute l'équipe.

La porte de sortie est force-unlock, avec l'ID lu dans l'erreur :

terraform force-unlock a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d

À manier comme une arme chargée. Forcer le déverrouillage alors qu'un apply tourne encore réellement réintroduit exactement la corruption par écriture concurrente que le verrou existait pour empêcher. Assurez-vous que le processus propriétaire est bien mort (vérifiez le job CI, interrogez la personne nommée dans Who) avant de déverrouiller. Ne câblez jamais force-unlock dans une automatisation, et ne dégainez pas -lock=false pour faire disparaître l'erreur : cela désactive le verrouillage pour de vrais apply.

La dérive, et pourquoi plan est votre détecteur

Le state part du principe qu'il est seul à modifier votre infrastructure. Quand quelqu'un édite une ressource à la main dans une console, ou qu'un autre outil y touche, le réel s'écarte de ce que le state enregistre. Cet écart, c'est la dérive (drift).

terraform plan est le détecteur : il rafraîchit le state à partir des attributs réels du fournisseur, puis compare la configuration, le state et la réalité. Un run en mode rafraîchissement seul isole la dérive pure des changements que vous voulez vraiment appliquer :

terraform plan -refresh-only

Si ce plan montre des différences sans aucune modification de configuration de votre côté, c'est que quelque chose a bougé hors de Terraform. Réconciliez de façon délibérée, soit en important et en codifiant le changement, soit en appliquant pour ramener le réel vers l'état déclaré. Faire tourner la détection de dérive de façon planifiée, comme une étape de votre pipeline CI/CD, transforme une divergence silencieuse en alerte, plutôt qu'en surprise lors du prochain déploiement sans rapport.

À retenir

Le state local est un défaut mono-joueur. Dès qu'une seconde personne ou un pipeline touche la même infrastructure, il faut un backend distant pour une source de vérité partagée et un verrou pour sérialiser les écritures. Le verrouillage n'est pas un obstacle à contourner : le flag -lock=false et le force-unlock réflexe sont la façon dont les équipes corrompent leur state. Et comme le state se croit seul acteur, planifiez plan pour attraper la dérive avant qu'elle ne vous attrape. C'est un socle de l'industrialisation de votre CI/CD posée sur de l'infrastructure as code qui tient sous charge.

Terraform Remote State and Locking: How It Actually Works

Fri, 24 Jul 2026 00:00:00 GMT

<!-- lang=en justification: "terraform state lock", "error acquiring the state lock" and "remote backend s3 dynamodb" are global technical queries typed almost entirely in English by engineers mid-apply. Consistent with publishing pointed reference tutorials in English.

Content note (JM directive 2026-07-24): reference tutorial, generic and verifiable end to end against Terraform documentation and backend behavior. No production anecdotes by design, this is not a REX. -->

Two engineers run terraform apply on the same stack within the same minute. Both read the state, both plan against it, both write back. The second write silently overwrites the first, and now the state file describes infrastructure that no longer matches reality. Nobody gets an error. This is the failure mode local state was never built to prevent, and the reason remote backends exist.

Why local state does not survive a team

Terraform keeps a state file that maps every resource in your configuration to a real object in your provider, plus metadata and dependency order. By default that file is terraform.tfstate, sitting on the laptop of whoever ran the last apply.

That default breaks the moment a second person joins:

It is not shared. Your colleague's state does not know about the resources you created. Their next plan wants to recreate them.
It has no lock. Nothing stops two applies from running at once, and Terraform's read-modify-write cycle is not atomic across machines.
It leaks secrets. State stores resource attributes in plaintext, including generated passwords and keys, now scattered across laptops and possibly Git.

A remote backend fixes all three: one authoritative copy, an access-controlled store, and a locking mechanism.

What a remote backend gives you

A backend is declared in the terraform block. The S3 backend is the common reference:

terraform {
  backend "s3" {
    bucket       = "acme-tfstate"
    key          = "platform/prod/terraform.tfstate"
    region       = "eu-west-1"
    encrypt      = true
    use_lockfile = true   # native S3 locking, Terraform 1.10+
  }
}

State now lives in S3, versioned and encrypted, and locking is handled by a lock file written next to it using S3 conditional writes. Historically that lock lived in a separate DynamoDB table (dynamodb_table with a LockID primary key); the DynamoDB approach still works, but native lock files removed the extra dependency for new stacks.

Other backends bundle the same idea differently. The GCS backend has locking built in, using object generation numbers, no side table required. HCP Terraform (formerly Terraform Cloud) manages the state store and the lock for you, and adds run history and access policy on top.

How the lock actually works

Before any operation that could write state (apply, and plan when it refreshes), Terraform acquires a lock. The lock is a small record holding who took it, which operation, when, and a unique ID. While it is held, a second run refuses to start:

$ terraform apply
╷
│ Error: Error acquiring the state lock
│
│ Lock Info:
│   ID:        a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d
│   Operation: OperationTypeApply
│   Who:       alice@build-runner-07
│   Created:   2026-07-24 09:14:22 UTC
╵

This is the system working correctly. The lock is released automatically when the operation finishes, whether it succeeds or fails cleanly.

The classic trap: the stale lock

The lock is only released cleanly if Terraform gets to release it. Kill the process with Ctrl-C twice, lose the network mid-apply, or have a CI runner evicted, and the lock stays held with no owner behind it. Every subsequent run then fails with the same Error acquiring the state lock, blocking the whole team.

The escape hatch is force-unlock, using the ID from the error:

terraform force-unlock a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d

Treat this as a loaded gun. Force-unlocking while another apply is genuinely still running reintroduces the exact concurrent-write corruption the lock existed to prevent. Confirm the owning process is truly dead (check the CI job, ask the person named in Who) before you unlock. Never wire force-unlock into automation, and never reach for -lock=false to make the error go away, that disables locking for real applies.

Drift, and why plan is your detector

State assumes it is the only thing changing your infrastructure. When someone edits a resource by hand in a console, or another tool touches it, the real world diverges from what state records. That gap is drift.

terraform plan is the detector: it refreshes state against the provider's real attributes, then compares config, state, and reality. A refresh-only run isolates pure drift from changes you actually intend:

terraform plan -refresh-only

If that shows differences with no config changes on your side, something outside Terraform moved. Reconcile deliberately, either by importing and codifying the change or by applying to pull reality back to the declared state. Running drift detection on a schedule, as a step in your CI/CD pipeline, turns silent divergence into an alert instead of a surprise during the next unrelated deploy.

What to remember

Local state is a single-player default. The moment a second person or a pipeline touches the same infrastructure, you need a remote backend for a shared source of truth and a lock to serialize writes. Locking is not an obstacle to route around: the -lock=false flag and a reflexive force-unlock are how teams corrupt state. And because state trusts that it is the only actor, schedule plan to catch drift before it catches you. Getting this right is foundational to industrializing your CI/CD on top of infrastructure as code.

Le blog de Joseph Delassalle — platform engineering & SRE

Instrumenter une app Prometheus : golden signals

Les quatre signaux, et par où commencer

Le bon type de métrique pour la bonne question

Un handler instrumenté, et les requêtes qui vont avec

Histogramme ou summary : pourquoi le quantile se calcule côté serveur

Les buckets, l'interpolation, et les pièges

À retenir

PodDisruptionBudget : contre quoi il protège vraiment

Perturbations volontaires et involontaires

minAvailable contre maxUnavailable

Interaction avec les drains et l'autoscaler

Erreurs de configuration classiques

À retenir

PodDisruptionBudget: What It Actually Protects Against

Voluntary versus involuntary disruptions

minAvailable versus maxUnavailable

Interaction with drains and the cluster autoscaler

Common misconfigurations

What to remember

Readiness, Liveness and Startup Probes in Kubernetes

Three probes, three different questions

readinessProbe: can this pod serve traffic right now?

livenessProbe: is this process wedged beyond recovery?

startupProbe: has this container finished booting?

Probe mechanics and parameters

The failure modes of copy-pasted probes

Liveness and readiness pointing at the same endpoint

Dependency checks inside the liveness probe

No startupProbe on a slow-starting application

No readinessProbe at all

tcpSocket where httpGet was needed

A complete example

Decision table

What probes do not solve

Kubernetes requests vs limits: throttling, OOMKill and QoS

Requests and limits do different jobs

Crossing the CPU limit: throttling

Crossing the memory limit: OOMKill

QoS classes are derived, not declared

The "no CPU limits" argument

A method for setting defaults

Common pitfalls

What to remember

kubectl rollout undo : comment fonctionnent les rollbacks

Les révisions sont des ReplicaSets, pas des snapshots

Ce que rollout undo fait réellement

Ce qu'un rollback ne restaure pas

Le nombre de réplicas

ConfigMaps, Secrets, et tout ce qui entoure le pod

Tout ce qu'a fait un Deployment en pause

revisionHistoryLimit : jusqu'où vous pouvez remonter

Le change-cause manquant, et savoir vers quoi on revient

rollout undo face à un revert Git

Aide-mémoire

kubectl rollout undo: How Kubernetes Rollbacks Work

Revisions are ReplicaSets, not snapshots

What rollout undo actually does

What a rollback does not restore

Replica count

ConfigMaps, Secrets, and everything around the pod

Anything a paused Deployment did

revisionHistoryLimit: how far back you can reach

The missing change-cause, and knowing what you are rolling back to

rollout undo vs a Git revert

Quick reference

Symptom-based Prometheus alerts that don't page at 3am

Symptom-based versus cause-based

How for and severity actually work

A bad rule rewritten into a good one

Pitfalls that survive good intentions

What to keep

Probes Kubernetes : readiness, liveness et startup

Trois probes, trois questions différentes

readinessProbe : ce pod peut-il servir du trafic maintenant ?

livenessProbe : ce processus est-il bloqué au point d'être irrécupérable ?

startupProbe : ce conteneur a-t-il fini de démarrer ?

Mécanique et paramètres des probes

Les modes de défaillance des probes copiées-collées

Liveness et readiness pointant sur le même endpoint

How `for` and severity actually work

Ce que font vraiment `for` et le label de sévérité