Skip to content

Sprint 5 — Frontend & Polish

Incidents du Sprint 5 : accĂšs plateforme (SSO), capacitĂ© du nƓud, tracing, frontend.

INC-060 : saturation du nƓud unique — le redĂ©ploiement Grafana fait tomber tout l'ingress

SĂ©vĂ©ritĂ© : High Statut : ✅ RĂ©solu — dĂ©clencheur corrigĂ© (!195) + gouvernance validĂ©e from-scratch (2026-06-25) + capacitĂ© #114 (2 node groups core/observability) validĂ©e live le 2026-06-27 : la stack obs isolĂ©e sur le nƓud Spot taintĂ©, prometheus enfin Running, le nƓud core redescend Ă  75 % de requests mĂ©moire. Un pic obs ne peut plus tuer le chemin de trafic (nƓuds distincts). #112 et #114 clos ensemble (ADR 026)

Contexte : Validation live des accĂšs plateforme (#105/#106) le 2026-06-23. Cluster mono-nƓud t3.medium (2 vCPU / ~3931 Mi) portant toute la pile : app FastAPI, Envoy/NLB, ArgoCD, cert-manager, ESO, ExternalDNS, Cilium + Hubble, kube-prometheus-stack, Loki + Alloy. ArgoCD redĂ©ploie Grafana aprĂšs le correctif d'env de #111.

SymptĂŽme : Grafana met ~6 min Ă  devenir Ready, puis les 3 hĂŽtes publics deviennent injoignables (api / argocd / grafana → connection timeout) pendant ~10 min. kubectl get events montre une rafale simultanĂ©e de Killing ... failed liveness probe sur ~11 pods (cilium-operator, metrics-server, argocd-server, argocd-repo-server, hubble-ui, node-exporter, fastapi, envoy-gateway, plan de donnĂ©es Envoy, prometheus, external-dns). Le plan de donnĂ©es Envoy (backend du NLB, partagĂ© par tous les hĂŽtes) redĂ©marre → plus aucune cible saine → coupure totale de l'ingress.

Cause : Le nƓud est sur-engagĂ© : limits.memory cumulĂ©es = 168 % de la capacitĂ© du nƓud (CPU 103 %). Il tient ~100 min, mais le redĂ©ploiement de Grafana dĂ©clenche un pic mĂ©moire + CPU : Grafana 11+/13 prĂ©installe plusieurs plugins au boot (lokiexplore, pyroscope, exploretraces, metricsdrilldown) et les re-tĂ©lĂ©charge Ă  chaque dĂ©marrage car le stockage est en emptyDir (persistence off). Ce pic fait basculer le nƓud sur-souscrit → kubelet qui ne rĂ©pond plus → NodeNotReady qui flappe → Ă©checs de liveness en masse. Ni HPA, ni Karpenter, ni Cluster Autoscaler ne l'auraient Ă©vitĂ© : ils rĂ©agissent aux pods Pending, pas Ă  l'overcommit au runtime.

RĂ©cupĂ©ration : Le nƓud s'est stabilisĂ© seul une fois Grafana bootĂ© (~11 min) ; supprimer le pod de plan de donnĂ©es Envoy coincĂ© a donnĂ© un backend NLB sain → accĂšs rĂ©tabli.

Fix : 1. DĂ©clencheur (!195) ✅ validĂ© live 2026-06-25 : GF_PLUGINS_PREINSTALL_DISABLED=true sur Grafana (supprime le pic de boot, dĂ©marrage rapide et sobre) + liveness probe assouplie (initialDelaySeconds 90, failureThreshold 12). Boot from-scratch propre, api 200, aucune cascade. C'est le gain anti-incident immĂ©diat. 2. Discipline des ressources (!196/!197/!199) ✅ validĂ©e from-scratch : requests/limits mesurĂ©s (!196) + LimitRange (defaults par namespace). Constat live #1 : le LimitRange livrĂ© en GitOps (sync-wave 2) arrivait aprĂšs les composants dĂ©jĂ  dĂ©marrĂ©s → ils restaient BestEffort (un LimitRange n'agit qu'Ă  l'admission). CorrigĂ© (!199) : dĂ©placĂ© au bootstrap Ansible, crĂ©Ă© avant tout composant → 2e boot from-scratch = plus aucun BestEffort. ResourceQuota reportĂ© Sprint 6. Nuance honnĂȘte : la somme des limits.memory monte (168→235 %) car borner les pods jusque-lĂ  non capĂ©s la fait croĂźtre tout en rĂ©duisant le risque (aucun runaway possible) ; ce n'est pas l'indicateur de risque. 3. CapacitĂ© (#114, ADR 026) — le vrai fix, ✅ validĂ© live le 2026-06-27 : avec des requests honnĂȘtes, le t3.medium montait Ă  99 % de requests mĂ©moire et prometheus ne se planifiait plus (Insufficient memory, pas de MemoryPressure : sur-rĂ©servation, pas sur-usage). Choix assumĂ© : garder les requests honnĂȘtes (pas de plancher-jeton Ă  remonter ensuite). Le 2e node group observability (Spot taintĂ©, t3.large) isole les workloads gourmands ET fournit la capacitĂ© qui manque. Validation from-scratch (2026-06-27) : prometheus enfin Running sur le nƓud Spot, core Ă  75 % de requests et observability Ă  21 % (marge pour Tempo), api 200. Économie Spot mesurĂ©e ~-70 %. DĂ©tails : ADR 026 (capacitĂ©) + ADR 025 (gouvernance).

Limite d'observabilitĂ© (leçon dans la leçon) : Prometheus / Loki / Alloy sont co-localisĂ©s sur le mĂȘme nƓud et sans persistance → ils ont redĂ©marrĂ© aussi et perdu leur TSDB/donnĂ©es, laissant un trou exactement pendant l'incident. Une stack de monitoring ne peut pas s'observer elle-mĂȘme quand son nƓud tombe. La chronologie vit dans kubectl get events, pas dans Loki (Alloy expĂ©die les logs de pods, pas les Events K8s).

Leçon : Un nƓud unique sur-engagĂ© est une bombe Ă  retardement : tant que rien ne pique, ça tient ; le premier pic transitoire (boot, migration, redĂ©ploiement) fait tout tomber. Trois rĂ©flexes : (1) dimensionner sur le pic, borner l'overcommit (requests honnĂȘtes + quota sur les limits) ; (2) isoler les workloads gourmands et jetables (observabilitĂ©) du chemin de trafic critique (un pic obs ne doit jamais pouvoir tuer le pod qui sert le trafic) ; (3) ne pas attendre d'un autoscaler qu'il rattrape un overcommit runtime, il ne voit que le Pending. Voir le guide CapacitĂ© et ressources.

INC-061 : metrics-server injoignable sous Cilium — kubectl top et le HPA cassĂ©s en silence

SĂ©vĂ©ritĂ© : Medium Statut : ✅ RĂ©solu — fix hostNetwork validĂ© live le 2026-06-25 (#115)

Contexte : DĂ©couvert le 2026-06-24 pendant la campagne de mesure de capacitĂ© du #112. Pour relever le working set par pod, on tente kubectl top → Ă©chec. La pile tourne sous overlay Cilium (#80) depuis la migration VPC CNI → Cilium.

SymptĂŽme : kubectl top nodes / kubectl top pods renvoient error: Metrics API not available. L'APIService agrĂ©gĂ© v1beta1.metrics.k8s.io est Unavailable, avec dans son message Address is not allowed vers l'IP overlay 10.42.0.208 (le pod metrics-server). Les mesures ont dĂ» ĂȘtre prises autrement (Prometheus / cAdvisor via port-forward).

Cause : Jumeau exact d'INC-058, transposĂ© d'un webhook Ă  un APIService agrĂ©gĂ©. metrics-server est servi par un pod ; l'API server EKS managĂ© dĂ©lĂšgue les requĂȘtes metrics.k8s.io Ă  ce pod (c'est l'API server qui appelle le pod). Sous overlay, le pod a une IP 10.42.x hors VPC → le control plane managĂ© (qui ne participe pas Ă  l'overlay VXLAN) ne sait pas la router → Address is not allowed. Effet de bord vicieux : le HPA fastapi (#82) consomme metrics.k8s.io → privĂ© de mĂ©triques, il a cessĂ© de scaler en silence dĂšs la migration #80, sans erreur visible (un HPA sans mĂ©triques n'alerte pas, il s'arrĂȘte juste de rĂ©agir). Bug latent ~6 jours.

Fix (#115, MR fix/115-metrics-server-cilium) : hostNetwork: true sur metrics-server (bootstrap Ansible) → le pod prend l'IP du node (10.0.x, VPC), de nouveau routable par le control plane. containerPort dĂ©calĂ© sur 10262 (donc --secure-port=10262) pour ne pas heurter le 10250 du kubelet, ni 10260 (cert-manager) ni 10261 (ESO) dĂ©jĂ  pris par les webhooks hostNetwork d'INC-058 sur ce cluster mono-nƓud.

ValidĂ© live (2026-06-25, boot from-scratch) : pod metrics-server sur l'IP du node 10.0.4.38 (plus d'IP overlay), APIService metrics.k8s.io Available=True, kubectl top nodes/pods rĂ©pondent, et kubectl get hpa -n fastapi affiche des TARGETS chiffrĂ©es (cpu: 3%/70%, memory: 58%/80%, plus de <unknown>) — le HPA fastapi est de nouveau alimentĂ©.

Leçon : La rĂšgle d'INC-058 ne se limite pas aux webhooks : tout composant que l'API server doit appeler (webhook d'admission/conversion ou APIService agrĂ©gĂ©) doit ĂȘtre joignable depuis le VPC → sous overlay, hostNetwork. Et un HPA sans mĂ©triques Ă©choue en silence : il faut surveiller activement l'Ă©tat de la metrics API (kubectl top ou une alerte sur l'APIService), sinon une dĂ©pendance cassĂ©e passe inaperçue tant qu'aucune charge ne rĂ©clame de scale. Voir le guide Cilium.

#109 — Frontend : la base « minimale » n'est pas Ă  jour

Type : leçon (build / supply chain), pas un incident de prod Statut : chaßne CI livrée (MR3), image à 0 CVE

Constat : le tag nginxinc/nginx-unprivileged:1.27-alpine, réputé minimal, embarque un alpine figé à sa publication. Premier scan Trivy de l'image frontend : 31 CVE HIGH/CRITICAL fixables (openssl, musl, zlib, libxml2, libpng, nghttp2...). Aucune due à notre code : paquets OS dont le correctif existe déjà en amont mais que la base n'a pas intégré.

Fix : apk upgrade --no-cache au runtime (bref USER root puis retour USER 101) → 0 CVE fixable, 0 au total. MĂȘme philosophie que le back (#67, #71).

Leçon : « image minimale » ≠ « image Ă  jour ». Un pin par digest est reproductible mais gĂšle aussi l'Ă©tat de patch de la base. Le pin (reproductibilitĂ©) et l'apk upgrade (fraĂźcheur des correctifs) sont complĂ©mentaires, pas contradictoires.

ChaĂźne CI : build-frontend-candidate + trivy-frontend-image-scan (double-gate + SBOM), mĂȘme politique que le back, sans exceptions hĂ©ritĂ©es.

#110 — Frontend : vertical slice validĂ©e live

Type : validation live (deploy GitOps + routing + intĂ©gration), pas un incident Statut : ✅ ValidĂ© live le 2026-07-02 — #110 fermĂ©

Ce qui est prouvé (bout en bout, boot from-scratch) :

  • app.devopsyouss.com sert la SPA React, servie par le Gateway partagĂ© (HTTPRoute cross-ns Accepted=True, CNAME ExternalDNS → NLB). L'Application ArgoCD frontend est Synced/Healthy, 2 replicas Running.
  • La SPA fait un fetch cross-origin vers api.devopsyouss.com/posts/public (endpoint public lecture seule, #110 MR1).
  • CORS strict validĂ© : Origin: https://app.devopsyouss.com → rĂ©ponse avec access-control-allow-origin: https://app.devopsyouss.com ; toute autre origine (test avec evil.com) → aucun access-control-allow-origin (moindre privilĂšge, pas de wildcard). Le access-control-allow-credentials: true renvoyĂ© sur les deux est un en-tĂȘte statique qui n'autorise rien seul : ce qui gouverne l'accĂšs cĂŽtĂ© navigateur, c'est allow-origin.
  • Le feed (#124) s'affiche avec les posts. Base RDS vide au dĂ©part → seed de 2-3 posts via l'API publique (POST /users/ → POST /login en form-encoded → POST /posts/ Bearer).
  • Image servie = deployed-<sha> (pas candidate-, blindage expiration ECR #104).

Deux findings annexes, non bloquants (issues de suivi créées) :

  • #125 — tempo-0 OOMKilled une fois dans la fenĂȘtre de boot (exit 137) sous le burst de spans de la validation (sampling 100 %, ADR 027), puis steady-state stable Ă  ~46Mi. Pistes : exclure les probes de l'auto-instrumentation (OTEL_PYTHON_EXCLUDED_URLS), sampling cĂŽtĂ© OTel Collector, ou bump modeste de la limite Tempo.
  • #126 — les 2 replicas frontend sont co-localisĂ©s sur le nƓud core (seul nƓud Ă©ligible : le nƓud observability est taintĂ© et le front n'a pas de toleration). topologySpreadConstraints Ă  ajouter pour la HA quand le node group core scale ≄2.

Leçon : une vertical slice frontend ne se prouve que live de bout en bout. Le rendu de la page dans le navigateur atteste d'un coup le service statique (Gateway → nginx), le fetch cross-origin, le CORS prod et le contrat /posts/public. La validation locale (compose miroir :3000→:8080) couvre le CORS, mais pas le routing Gateway ni la rĂ©solution DNS : ces deux-lĂ  ne se voient qu'en live.

#128 — Frontend V2 validĂ©e live

Type : validation live (parcours utilisateur complet), pas un incident Statut : ✅ ValidĂ© live le 2026-07-04 — #128 fermĂ© (code mergĂ© le 2026-07-03, !233→!235)

Ce qui est prouvé sur app.devopsyouss.com (boot from-scratch) :

  • Cycle complet register → login → JWT en conditions rĂ©elles.
  • CrĂ©ation de post (visible en tĂȘte de feed sans re-fetch) et vote (bouton reflĂšte l'Ă©tat serveur via les codes 201/409).
  • Recherche par mot-clĂ© et pagination (« Charger plus ») sur un jeu de 7 posts.
  • Panneau dĂ©tail (GET /posts/{id} Bearer) affiche les bonnes donnĂ©es.

Finding annexe (non bloquant, backlog) : le panneau dĂ©tail s'affiche dans un bloc fixe en haut de page plutĂŽt qu'au fil du post cliquĂ© — correct fonctionnellement, mais peu lisible avec plusieurs posts. TraitĂ© avec le CRUD complet (issue dĂ©diĂ©e, voir plus bas).

#117 + #125 — Service graph Tempo + fix OOM boot validĂ©s live

Type : validation live (observabilitĂ©), pas un incident Statut : ✅ ValidĂ© live le 2026-07-04 — #117 et #125 fermĂ©s (MR1 hors infra !236 mergĂ©e le 2026-07-03)

Ce qui est prouvé (boot from-scratch) :

  • tempo-0 et otel-collector Running, RESTARTS: 0 depuis le boot — le correctif OTEL_PYTHON_EXCLUDED_URLS=healthz,metrics (ADR 027 addendum) tient : plus d'OOM au boot constatĂ© sur #125.
  • Service Graph visible dans l'onglet Node Graph de Grafana (datasource Tempo) : arĂȘte fastapi → fastapi_db, cohĂ©rente avec le seul service applicatif instrumentĂ© (#107, FastAPI + SQLAlchemy — ni Envoy Gateway ni la SPA frontend, dont le fetch part du navigateur, ne gĂ©nĂšrent de spans serveur).

Leçon : un graphe de service « minimal » n'est pas un dĂ©faut de configuration quand le pĂ©rimĂštre d'instrumentation l'est aussi — vĂ©rifier le scope avant de chercher un bug.

#130 — Frontend V3 validĂ©e live

Type : validation live (CRUD + polish), pas un incident Statut : ✅ ValidĂ© live le 2026-07-04 — #130 fermĂ© (code mergĂ© le 2026-07-04, !238/!239)

Ce qui est prouvĂ© sur app.devopsyouss.com (mĂȘme boot from-scratch que #128 et #117/#125) :

  • Édition et suppression de ses propres posts depuis la SPA : boutons visibles uniquement sur ses posts (check owner.email cĂŽtĂ© UI), l'API restant l'autoritĂ© (PUT/DELETE /posts/{id} owner-only, 403 sinon). Confirmation avant suppression, curseur de pagination dĂ©calĂ© aprĂšs un delete.
  • DĂ©tail inline : le panneau dĂ©tail s'affiche dĂ©sormais sous le post cliquĂ© (toggle), correction du finding de la validation #128.
  • Footer stack DevOps : logos de la stack en SVG inline (simple-icons CC0, aucun chargement externe au runtime), liens vers les livrables live (repo, ArgoCD, Grafana, API docs, doc). Badge texte pour AWS EKS (logo AWS retirĂ© de simple-icons Ă  la demande d'AWS).

Leçon : livrer la V3 dans la foulĂ©e de la validation V2 (findings du matin → issue #130 → 2 MR → validation live le soir mĂȘme) n'a Ă©tĂ© possible que parce que les endpoints PUT/DELETE existaient dĂ©jĂ  cĂŽtĂ© API — le coĂ»t marginal d'une itĂ©ration frontend est faible tant que le contrat back tient la promesse.