ADR 025 — Gouvernance des ressources : requests/limits mesurés, QoS, LimitRange et ResourceQuota (2026-06-24)

Statut

Accepté (2026-06-24). Right-sizing (Décision 1/2) + LimitRange au bootstrap (Décision 3) validés live from-scratch le 2026-06-25 (no BestEffort dans les 8 namespaces possédés). ResourceQuota reporté Sprint 6. La validation a révélé que des requests honnêtes sur-souscrivent le nœud unique (requests mémoire à 99 %, prometheus non planifiable) → #114 (capacité) devient un prérequis dur ; #112 reste ouvert et sera clos avec #114 (voir « Validation live »). Issue #112, né de l'incident INC-060. ADR compagnon : ADR 026 (segmentation des node groups + Spot, #114) traite le volet « capacité matérielle » ; le présent ADR traite le volet « discipline des ressources ».

Contexte

L'incident INC-060 a coupé tout l'ingress (~10 min) sur le nœud unique t3.medium : un redéploiement de Grafana a déclenché un pic mémoire qui a fait basculer un nœud sur-engagé (limits.memory cumulées = 168 % de la capacité). Le déclencheur (préinstall des plugins Grafana) est traité à part. La cause racine est l'overcommit sans garde-fou : les pods se planifient sur des requests sous-évaluées, mais la pression au runtime vient des limits, et rien n'empêche leur somme de dépasser la capacité physique.

À l'approche de Tempo (#108, gourmand) et d'un 2e workload (frontend #109), continuer sans gouvernance rejouerait l'incident.

Décision 1 — Dimensionner sur la mesure, pas sur l'intuition

On relève la consommation réelle par pod (régime stable et pic) avec l'outillage déjà en place (Prometheus + kube-state-metrics + node-exporter) :

• Mémoire : container_memory_working_set_bytes (c'est la métrique qui déclenche l'OOMKill, pas le RSS).
• CPU : rate(container_cpu_usage_seconds_total[5m]).
• Aide à la recommandation : VPA en mode recommender (Off) ou Goldilocks (dashboard de reco par namespace), sans appliquer automatiquement.

Décision 2 — Régler mémoire et CPU différemment (compressible vs non)

• Mémoire (non compressible → dépassement = OOMKill) : request = working set en régime + marge ; limit couvre le pic mesuré (+ ~15-20 %). Sur les composants critiques, request = limit → classe QoS Guaranteed (les derniers évincés sous pression).
• CPU (compressible → dépassement = throttling, pas de kill) : request = usage p95 ; limit large ou absente sur le latency-sensitive (le throttling CPU fait souvent plus de mal qu'un léger dépassement). Arbitré selon ce que le check kube-linter exige en CI.

Décision 3 — Border par namespace : LimitRange + ResourceQuota

• LimitRange (defaults par namespace) : tout pod sans requests/limits hérite de valeurs par défaut → plus de pod BestEffort qui se faufile. Placement (corrigé en live, voir plus bas) : un LimitRange n'agit qu'à l'admission du pod (defaults injectés à la création, jamais rétroactivement). Il doit donc exister avant les pods → il est créé au bootstrap (Ansible), avant tout composant, et non par une Application GitOps qui se synchronise trop tard. Poulet/œuf assumé : une gouvernance qui doit précéder ArgoCD ne peut pas être gérée par ce même ArgoCD.
• ResourceQuota plafonnant la somme des limits.memory par namespace (reporté Sprint 6) → c'est le garde-fou qui rendrait l'overcommit mémoire structurellement impossible à l'admission. Nuance acquise en live : la somme des limits n'est pas la cause directe d'INC-060 (les limits ne réservent rien) ; le quota reste utile comme plafond dur, mais le vrai levier anti-incident immédiat a été le déclencheur (préinstall Grafana, !195) et la capacité (#114).

Conséquences

• L'incident INC-060 ne peut plus se reproduire par overcommit : un déploiement qui ferait dépasser le quota est refusé à l'admission, au lieu de tuer le nœud au runtime.
• Les valeurs (requests/limits, plafond de quota) se calent et se valident en live (MR3) : un quota trop serré bloquerait les déploiements, donc il se vérifie sur le cluster réel, pas seulement par helm template.
• Classe QoS explicite sur le critique → comportement d'éviction prévisible sous pression.
• Alternatives écartées : monter un nœud plus gros sans gouvernance (déplace le mur sans le supprimer) ; Karpenter tout de suite (ne corrige pas l'overcommit runtime, il réagit au Pending — donc inutile sans requests honnêtes ; reporté Sprint 6).

Validation live (2026-06-25)

Boot from-scratch, mesures par pod via Prometheus (metrics-server réparé en parallèle, #115/INC-061).

• Déclencheur (!195) ✅ : cluster monté propre, api 200, aucune cascade NodeNotReady au redéploiement Grafana (préinstall plugins désactivé). C'est le gain anti-incident immédiat.
• Right-sizing (!196) ✅ : valeurs mesurées bien déployées (fastapi req 100m/128Mi limit 256Mi ; argocd-application-controller req 512Mi limit 1Gi — le runaway BestEffort à ~800Mi est désormais capé ; grafana et prometheus req 384Mi limit 512Mi).
• Nuance honnête sur l'overcommit : la somme des limits.memory du nœud est montée (168 % → 217 %), pas baissée. Ce n'est pas un échec : c'est l'effet mécanique d'avoir donné une limite explicite (1Gi) à un gros pod jusque-là non borné (BestEffort = 0 dans la somme). Borner un runaway fait monter la somme des limits tout en réduisant le risque réel. La métrique qui compte est ailleurs : requests mémoire à 91 % → nœud tendu, ce qui confirme que le vrai fix capacité est #114, pas le right-sizing seul.
• LimitRange (!197 → !199) — trou trouvé puis corrigé, reprouvé from-scratch ✅ : livré en GitOps (sync-wave 2), il arrivait après les composants déjà démarrés → ~14 pods plateforme (argocd, cert-manager, ESO, external-dns) restaient BestEffort (un LimitRange n'agit qu'à l'admission). Corrigé (!199) : LimitRange déplacé au bootstrap Ansible, créé avant tout composant. 2e boot from-scratch (2026-06-25) : plus AUCUN BestEffort dans les 8 namespaces possédés, fastapi né restricted (PSA) une seule fois, LimitRange présent partout avant les pods.

La gouvernance honnête révèle la sur-souscription (le vrai enseignement)

Conséquence directe et assumée du LimitRange efficace : chaque pod jusque-là BestEffort réserve désormais le defaultRequest (64Mi). Sur le boot from-scratch, le nœud unique t3.medium est monté à 99 % de requests mémoire (3286Mi / ~3319 allouables) → prometheus-kps-prometheus-0 (request 384Mi) ne peut plus être planifié (FailedScheduling: Insufficient memory). À noter : MemoryPressure: False — c'est de la sur-réservation (somme des requests), pas un manque de RAM réelle (usage ~69 %) ; les pods ne consomment pas ces 64Mi, ils bloquent juste le scheduler.

Décision (assumée avec Youssef) : ne PAS band-aider en baissant le defaultRequest à un plancher-jeton (16Mi) qu'il faudrait remonter ensuite. On garde des requests honnêtes (64Mi) : c'est future-correct (dès que la capacité existe, tout se planifie sans rien retoucher). La gouvernance par réservations et la capacité sont couplées : on ne peut pas réserver un plancher pour chaque pod sur un nœud déjà plein.

→ #114 (ADR 026) passe de « souhaitable » à prérequis dur, prouvé par la mesure (requests à 99 %). #112 reste ouvert : la gouvernance est livrée et validée (no BestEffort, runaways capés), mais la stack ne planifie entièrement qu'après #114 (capacité). On clôt #112 avec #114.

Évolution possible

• ADR 026 (#114) : segmenter en node groups core (on-demand) / observability (Spot) pour isoler les workloads gourmands du trafic.
• Karpenter (Sprint 6) : une fois les requests fiables, l'autoscaling des nœuds devient pertinent (il se déclenche sur le Pending, qui dépend des requests).

---

Date : 2026-06-24 Sprint : 5 Issue : #112 (INC-060)