ADR 026 — Segmentation des node groups : core (on-demand) / observability (Spot) (2026-06-26)

Statut

Validé live (2026-06-27) — validation from-scratch complète : les deux node groups montent, la stack obs atterrit sur le nœud Spot tainté, prometheus passe enfin Running, le trafic reste stable sur core. ADR compagnon : ADR 025 (gouvernance des ressources, #112) traite le volet « discipline des ressources » ; le présent ADR traite le volet « capacité matérielle ». Issue #114 (née de #112 / INC-060). #112 clos avec #114.

Contexte

La validation from-scratch de la gouvernance (#112, ADR 025, 2026-06-25) a mesuré le mono-node t3.medium à 99 % de requests mémoire (3286Mi / ~3319 allouables), avec prometheus-kps-prometheus-0 non planifiable (FailedScheduling: Insufficient memory, MemoryPressure: False → sur-réservation, pas manque de RAM réelle). Décision assumée (ADR 025) : garder des requests honnêtes plutôt que de baisser un plancher-jeton. Conséquence directe : sans capacité supplémentaire, la stack gouvernée ne planifie pas entièrement.

S'ajoutent deux faiblesses structurelles révélées par INC-060 (le pic Grafana qui a coupé l'ingress ~10 min) :

1. Observabilité co-localisée au chemin de trafic : le pic mémoire de Grafana a tué le nœud qui portait aussi Envoy/NLB → api + argocd + grafana à 000. L'obs et le trafic critique partageaient le même destin.
2. Arrivée de Tempo (#108) : l'ingestion de traces va alourdir encore la stack obs, déjà la plus gourmande.

Décision — Deux managed node groups séparés par taint / tolerations / nodeSelector

Node group	Capacité	Type de départ	Porte	Pourquoi
core	on-demand	t3.medium	API FastAPI, Envoy/NLB, ArgoCD, cert-manager, ESO, ExternalDNS	stabilité du trafic + plateforme : pas d'éviction Spot sur le chemin critique. Une fois l'obs partie, core ≈ 2Gi sur 3.3 → marge ample pour l'HPA de l'app
observability	Spot (tainté)	t3.large diversifié (t3.large / t3a.large / m5.large)	Prometheus, Loki, Tempo (#108), Grafana, Alloy	gourmand et croissant (Tempo), mais jetable (pas de persistance, perdu au teardown 20h) → on met le gros nœud sur le moins cher (Spot ~-70 %)

Mécanisme d'isolation :

• Le node group observability porte le taint workload=observability:NoSchedule + le label workload=observability.
• Côté k8s (MR2), les workloads obs portent une toleration de ce taint + un nodeSelector workload=observability : la toleration autorise l'atterrissage sur le nœud tainté, le nodeSelector l'y force (sinon ils pourraient retomber sur core).
• Les workloads core ne portent rien : le taint les repousse automatiquement du nœud obs.
• Piège DaemonSets : node-exporter (métriques nœud) et alloy (logs) doivent tourner sur tous les nœuds → toleration OUI, nodeSelector NON (sinon on perd la télémétrie du nœud core). Cilium tolère déjà tout nativement.

Pourquoi ce dimensionnement, anti-intuition assumée : l'instinct prod « mettre l'app sur le gros nœud » ne s'applique pas ici. L'API est volontairement légère (128Mi req, HPA plafonné à 5 ≈ 1.3Gi pic) et sans trafic réel (portfolio) : la dimensionner gros, c'est provisionner pour une charge qui ne viendra pas. Le vrai gourmand mémoire est l'observabilité (Prometheus/Grafana + Tempo) — c'est elle qui a saturé le nœud, donc elle qui va sur le gros nœud Spot. Le principe « trafic sur on-demand stable » reste respecté : core est on-demand et l'app y a la place de scaler. Les types sont un point de départ à confirmer en live (vraies mesures par pod).

Spot — précautions

• Interruption AWS avec 2 min de préavis → Spot pour le jetable uniquement, on-demand pour le critique.
• Pas de stateful in-cluster (la DB est sur RDS) → la contrainte Spot est souple : core reste on-demand pour ne pas couper le trafic à l'éviction, pas pour de la persistance.
• Diversifier les instance types du node group Spot (t3.large / t3a.large / m5.large) → meilleure disponibilité, moins d'interruptions.
• Sans autoscaler, une interruption = pods obs Pending jusqu'au prochain start. Acceptable pour un lab éphémère ; comblé par Karpenter (Sprint 6) qui reprovisionnerait sur un autre type Spot.

Conséquences

• #112 devient structurellement impossible : un pic obs ne peut plus tuer le nœud du trafic (nœuds distincts). L'isolation des pannes est matérielle, pas seulement logique.
• La stack gouvernée (requests honnêtes, ADR 025) planifie enfin : la capacité débloque prometheus (et la place pour Tempo).
• Le nœud le plus cher (celui qui absorbe Tempo) passe à ~-70 % via Spot.
• Coût : deux nœuds au lieu d'un, mais infra éphémère (teardown 20h) et le gros nœud est Spot → surcoût marginal.
• Renommage Terraform : l'ancien node group unique main devient core → destroy/create côté Terraform, sans conséquence sur infra éphémère (rien à migrer, recréée à chaque start).

Alternatives écartées

• Un seul nœud plus gros (ex. t3.xlarge) : règle la planification mais ne traite pas l'isolation (un pic obs tuerait toujours le trafic co-localisé) et coûte plein pot en on-demand.
• Tout en Spot : exposerait le trafic aux interruptions (api à 000 le temps du reschedule) — inacceptable pour le chemin critique.
• Karpenter tout de suite : très fort en entretien mais gros morceau (IAM, NodePool, consolidation) et inutile sans requests honnêtes (il scale sur le Pending, donc sur les requests). Séquencé après. Sprint 6 dédié.

Validation live (✅ 2026-06-27, from-scratch)

Les six points cochés sur un cluster monté de zéro :

• ✅ kubectl get nodes -L workload → deux nœuds, labels core (ip-10-0-4-89) et observability (ip-10-0-3-32).
• ✅ Taints → workload=observability:NoSchedule présent sur le nœud obs uniquement (core <none>).
• ✅ prometheus-kps-prometheus-0 2/2 Running, plus grafana, loki-0, alertmanager, kube-state-metrics, operator → tous sur le nœud obs. Le verdict de l'ADR : le 2026-06-25, ce même prometheus restait Pending (Insufficient memory) sur le mono-node ; ici il planifie.
• ✅ fastapi, argocd-server, envoy → sur le nœud core ; curl https://api.devopsyouss.com/healthz/ready → 200, trafic stable.
• ✅ node-exporter (2) et alloy (2) présents sur les deux nœuds (toleration joker operator: Exists).

Capacité mesurée après segmentation

Nœud	Type	requests mémoire	requests CPU
core	t3.medium on-demand	75 % (2504Mi)	65 %
observability	t3.large Spot	21 % (1492Mi)	31 %
mono-node (2026-06-25, pour mémoire)	t3.medium seul	99 % → prometheus Pending	—

Deux nœuds qui respirent là où le mono-node saturait à 99 % de requests mémoire. La marge à 21 % sur le t3.large Spot valide le dimensionnement « large à dessein » : Tempo (#108) y rentrera sans nouvelle capacité. (Rappel pédagogique : les limits cumulées peuvent dépasser 100 % — overcommit volontaire et sain ; ce qui gouverne la planification, ce sont les requests, pas les limits.)

• Facultatif (non fait) : simuler une interruption Spot et observer le reschedule (Pending sans autoscaler). Reporté à Karpenter / Sprint 6.

---

Date : 2026-06-26 Sprint : 5 Issue : #114 (capacité, né de #112 / INC-060)