Sprint 4 — Observabilité (Day-2 operations)

Incidents du Sprint 4 : GitOps ArgoCD, observabilité, densité de pods.

---

INC-053 : "Too many pods" — densité limitée par le VPC CNI (t3.medium)

Contexte : Installation d'ArgoCD (#72), 7 pods ajoutés sur le node unique.

Symptôme : 4 pods ArgoCD bloqués en Pending, FailedScheduling: 0/1 nodes are available: 1 Too many pods. Ce n'est pas un manque de CPU/mémoire (mesurés à 34 %).

Cause : Le VPC CNI d'AWS alloue une IP secondaire d'ENI par pod. Le max-pods est donc plafonné par le réseau, pas par le CPU/RAM. Sur t3.medium : 3 ENI × 6 IP − 1 = max-pods 17, déjà atteint par les pods système + opérateurs (Envoy, cert-manager, ESO, ExternalDNS, metrics-server) + fastapi.

Fix : Prefix Delegation du VPC CNI (ENABLE_PREFIX_DELEGATION=true, chaque ENI alloue des /28) couplée à un launch template nodeadm AL2023 forçant maxPods: 110. Résultat : max-pods 17 → 110. Détails et alternatives écartées : ADR 012.

Piège d'ordre rencontré : après le 1er apply, les pods restaient en ContainerCreating avec aws-cni ... failed to assign an IP address. Cause : l'addon CNI avait depends_on = [node_group], donc le node a booté ses ENI en mode IP classique avant que la Prefix Delegation soit active ; l'activer après coup ne reconfigure pas rétroactivement les ENI attachées (maxPods=110 mais le CNI ne fournit que ~17 IP). Déblocage immédiat : recycler le node (terminer l'instance, le node group en relance une qui boote en mode prefix). Fix durable : inverser la dépendance Terraform (node group depends_on aws_eks_addon.vpc_cni) pour que l'addon précède le boot des nodes au from-scratch. Validé le 2026-06-12 (aws-start from-scratch) : node Ready avec max-pods=110 dès le boot, aucun pod bloqué, aucun recyclage manuel.

Leçon : Sur EKS, max-pods est une limite réseau (ENI/IP), pas de ressources. Deux pièges en cascade : (1) un managed node group simple garde max-pods bas même avec la Prefix Delegation activée → launch template avec override maxPods obligatoire ; (2) l'addon CNI doit être configuré avant le boot des nodes, sinon ils restent en mode IP classique et il faut les recycler. À anticiper avant toute montée en densité (observabilité #74/#75). Solution AWS-native ici, à terme remplacée par Cilium (overlay = plus de contrainte d'IP par ENI). → fait en #80 / ADR 019 : la Prefix Delegation est retirée, l'overlay Cilium affranchit la densité du plafond ENI.

---

INC-054 : flapping de pods — ArgoCD selfHeal vs HPA sur spec.replicas

Contexte : Validation from-scratch du déploiement GitOps (#72) après l'infra-up. Le Deployment fastapi est piloté par un HPA (minReplicas: 1, maxReplicas: 5) et déployé par ArgoCD avec selfHeal: true.

Symptôme : Pods fastapi créés puis détruits en boucle. Le pod le plus ancien reste Running, les pods récents passent en Error (terminés en plein scale-down). L'Application ArgoCD fastapi oscille entre Synced et Progressing, sans jamais se stabiliser en Healthy.

Cause : Conflit de propriété sur spec.replicas. Le manifeste Git (k8s/base/deployment.yaml) fixait replicas: 2. À charge faible, le HPA descend le Deployment à replicas: 1. ArgoCD compare alors cluster (1) ≠ Git (2), juge le Deployment OutOfSync, et selfHeal réécrit replicas: 2. Le HPA retue aussitôt le pod surnuméraire. Retour à 1, ArgoCD remet 2… boucle infinie. Deux contrôleurs se disputent le même champ.

Fix : Retirer spec.replicas du manifeste (quand un HPA pilote le nombre de pods, le manifeste ne doit pas le fixer ; le HPA part de minReplicas) et ajouter un ignoreDifferences sur /spec/replicas dans l'Application ArgoCD (robustesse : si le champ réapparaissait, ArgoCD ne le réconcilierait pas). Best practice officielle ArgoCD (« ArgoCD fights with HPA »).

Leçon : En GitOps, un champ ne peut avoir qu'une seule source de vérité. Si un contrôleur dynamique (HPA, VPA, certains opérateurs) gère un champ, il faut le retirer de Git et dire à ArgoCD de l'ignorer, sinon selfHeal lui fait la guerre. Symptôme à reconnaître : une ressource qui ne se stabilise jamais en Healthy + un churn de pods sans cause applicative. Le réflexe : chercher les champs partagés entre Git et un contrôleur (replicas, annotations injectées…).

Effet de bord (kube-linter / PDB), corrigé via #83 : retirer replicas du Deployment a déclenché le check kube-linter pdb-min-available. En analyse statique, kube-linter ne lit pas le HPA : il suppose replicas: 1 (défaut) et le compare au PDB minAvailable: 1, concluant que le PDB bloquerait tout drain. Corrigé en passant le PDB en maxUnavailable: 1 (s'exprime relativement au nombre courant de pods, pas de blocage à 1 pod) et le HPA en minReplicas: 2 (toujours ≥2 pods → zéro downtime sur rolling update et drain de node). Trou de process découvert : la MR #82 a été mergée alors que le ci_config_path était sur .gitlab-ci-infra.yml, donc le job kube-linter-scan (défini dans le pipeline app) ne s'est jamais exécuté sur le changement de manifeste. Une MR qui touche k8s/ doit tourner sous le config path app, sinon les lints K8s sont contournés silencieusement.

---

INC-055 : loki-0 CrashLoopBackOff — /var/loki en read-only filesystem

Contexte : Premier déploiement de la stack logs (#75) sur le cluster via ArgoCD. Loki en mode SingleBinary, persistence: false (cluster éphémère, choix no-PVC de l'ADR 015).

Symptôme : loki-0 en CrashLoopBackOff (1/2 Ready, redémarrages répétés). Log : error running loki ... err="mkdir /var/loki: read-only file system\nerror initialising module: ruler-storage".

Cause : En SingleBinary sans persistence, le chart grafana/loki ne monte aucun volume sur le data path /var/loki (le PVC storage n'existe que si persistence.enabled: true). Le conteneur loki ayant readOnlyRootFilesystem: true, /var/loki retombe sur le rootfs en lecture seule → Loki ne peut pas créer ses répertoires de données (chunks, rules, wal, compactor) et plante au démarrage.

Fix : Monter un emptyDir inscriptible sur /var/loki via singleBinary.extraVolumes + extraVolumeMounts (éphémère, cohérent avec le choix no-persistence : les logs meurent au teardown). On garde readOnlyRootFilesystem: true (durcissement préservé), seul le data path devient inscriptible. Validé par helm template (volume data → /var/loki présent sur le conteneur).

Leçon : helm template valide le manifeste rendu, pas le comportement runtime. Le rendu était parfait (StatefulSet correct), mais le crash ne se voit qu'au démarrage réel du process (écriture sur un fs read-only). Même classe que INC-045/046 (« rendu/configuré statiquement ≠ fonctionne au runtime »). Réflexe pour tout composant stateful déployé sans PVC : vérifier qu'un volume inscriptible (emptyDir) est bien monté sur son data path, surtout quand le conteneur a readOnlyRootFilesystem: true.

INC-056 : Grafana OOMKilled au démarrage — limite mémoire trop basse

Contexte : Session de validation live from-scratch (2026-06-14, #76/#77/#70). Stack observabilité posée par ArgoCD. Grafana configuré avec limits.memory: 200Mi (values #74, dimensionnement volontairement serré pour le mono-node éphémère).

Symptôme : kube-prometheus-stack-grafana en CrashLoopBackOff. Conteneur grafana OOMKilled (Exit Code 137, Restart Count 3), readiness puis liveness en échec (connection refused au boot, puis context deadline exceeded). Un log d'erreur trompeur Failed to install plugin pluginId=elasticsearch ... unlinkat ...: permission denied a d'abord orienté le diagnostic vers un problème de plugin/permissions (red herring).

Cause : La limite mémoire de Grafana (200Mi) est trop basse pour Grafana 11+. En régime stable il tourne à ~161Mi, mais le pic au démarrage (migrations DB + gestion des plugins bundled) dépasse 200Mi → le kernel tue le conteneur (OOMKill, 137) avant qu'il devienne Ready → CrashLoop. Le node était à 82% mais n'est pas en cause : l'OOM est au niveau conteneur (limite), pas node. L'erreur de plugin est non fatale.

Fix : Remonter grafana.resources : limits.memory 200Mi → 768Mi (plafond anti-OOM large, absorbe le pic de boot), requests.memory 100Mi → 128Mi (modéré, pas de sur-réservation sur le node). Déployé en GitOps (MR values → merge develop → ArgoCD resync), même pattern que INC-055.

Leçon : La limite mémoire ≠ consommation. Une limite trop serrée tue un process sur un pic transitoire (boot, migration) même si le régime stable est largement sous la limite. Dimensionner la limite sur le pic, pas sur le régime, pour les composants qui chargent au démarrage (Grafana, JVM...). Monter une limite ne coûte rien au node en régime stable (seuls l'usage réel + les requests pèsent), donc autant la garder large. Et lire le bon signal : Exit Code 137 = OOMKill, c'était le vrai tueur ; le log d'erreur plugin était un red herring qui a fait perdre du temps au début (même réflexe que INC-044 : i/o timeout = réseau, 401 = auth, 137 = mémoire).

---

Validation alerting bout-en-bout + 2 limites détectées (2026-06-14)

Contexte : Session de test des alertes en conditions réelles (infra up), doublée d'une prise en main de Grafana. But : déclencher de vraies alertes FastAPI (#77) et observer toute la chaîne Prometheus → Alertmanager → Slack.

Ce qui a été validé (live) : - Cycle de vie complet d'une alerte : Normal → Pending → Firing → Resolved, et le rôle du for: (délai anti-faux-positif) observé en direct. - FastAPIPodCrashLooping ET FastAPITargetDown se déclenchent sur un CrashLoop provoqué, routées vers Slack par sévérité (critical), puis [RESOLVED] au rétablissement. - Diagnostic en direct via Grafana Explore (PromQL : up{...}, increase(kube_pod_container_status_restarts_total[10m])).

Limite 1 — up == 0 ne couvre pas la disparition totale de la cible. Au premier essai (scale à 0 du deployment), FastAPITargetDown ne s'est pas déclenchée : sans pod, il n'y a plus d'endpoint, donc plus de cible, donc la série up disparaît (elle ne vaut pas 0, elle n'existe plus). up == 0 n'a alors rien à évaluer. La même règle se déclenche en revanche très bien quand le pod existe mais plante (CrashLoop : cible présente, scrape KO → up = 0). Distinction « série absente » vs « série à 0 ». → Corrigé (#93) : règle FastAPITargetMissing (absent(up{namespace="fastapi", endpoint="http"}), severity: critical, for: 2m) ajoutée en complément de FastAPITargetDown. Les deux couvrent les deux faces de la panne (cible disparue vs cible présente qui ne répond pas). Validé live le 2026-06-16 : scale-à-0 réel du deployment → la série up disparaît de Prometheus → FastAPITargetMissing (critical) tire dans Slack après for: 2m, puis [RESOLVED] au retour des pods. La preuve par le comportement, pas par le YAML.

Limite 2 — InfoInhibitor remonte dans Slack. Lors du test live, l'alerte système InfoInhibitor (rouage interne du mécanisme d'inhibition) est arrivée dans Slack. Elle devrait être routée vers null comme le Watchdog. → Corrigé (#94) : matcher alertname = "InfoInhibitor" → receiver null ajouté dans le routing Alertmanager, comme le Watchdog. Validé live le 2026-06-16 : pendant le test #93, InfoInhibitor n'est pas remonté dans Slack (seul FastAPITargetMissing y est arrivé).

Bonus ArgoCD (vécu pendant la manip) : pour provoquer un CrashLoop durable il a fallu couper le selfHeal. Deux enseignements confirmés en test : (1) cascade app-of-apps — couper le selfHeal de fastapi ne suffit pas, le root-app apps le répare ; il faut museler le parent d'abord ; (2) ArgoCD est additif — un champ ajouté hors-bande (command: injecté par kubectl patch, absent du Git) n'est pas vu comme un drift : l'Application reste Synced et le selfHeal ne le retire pas. C'est voulu (coexistence avec HPA/webhooks/opérateurs, cf. INC-054). Retrait du champ → manuel (ou Replace=true).

Leçon : valider une alerte, ce n'est pas vérifier qu'elle est écrite, c'est la déclencher pour de vrai. Le test live a révélé un angle mort (up == 0) qu'aucune relecture du YAML n'aurait montré. Même principe que pour les manifests (INC-055 : helm template valide le rendu, pas le runtime) : la preuve, c'est le comportement, pas l'intention.

#81 — /metrics retiré de l'exposition publique (2026-06-15)

Contexte : depuis #73 l'app expose /metrics (Prometheus). Branché sur l'app principale, il était routé publiquement par effet de bord (la rule HTTPRoute PathPrefix: / attrape tout). Or /metrics est scrapé en interne par Prometheus (ServiceMonitor → ClusterIP, #74), jamais via le Gateway, et exposé publiquement il divulgue routes/latences/codes d'erreur (reconnaissance).

Correctif (ADR 018) : rule HTTPRoute dédiée PathPrefix: /metrics → HTTPRouteFilter directResponse 404 (CRD Envoy Gateway), référencé via ExtensionRef. Gateway API choisit le match le plus spécifique, donc /metrics tombe sur le 404 sans atteindre le backend ; la rule / reste pour le reste du trafic. 404 et non 403 : ne divulgue pas l'existence de l'endpoint. Aucune modif de l'app ni du scrape interne (le ServiceMonitor tape le ClusterIP, hors Gateway).

Validé hors infra : kustomize build k8s/base (exit 0), refs HTTPRoute → HTTPRouteFilter cohérentes, mkdocs build. Comme #70, pas d'outil hors cluster pour le CRD HTTPRouteFilter.

Validé live (2026-06-16) : curl https://api.devopsyouss.com/metrics → 404, et target fastapi toujours UP dans Prometheus (up{namespace="fastapi", endpoint="http"} == 1, scrape interne ClusterIP intact). ✅

INC-057 : kube-linter-scan rouge sur un download latest flaky (2026-06-15)

Symptôme : le pipeline develop passe rouge sur kube-linter-scan, stages suivants (build, promote, pages) skipped, sans aucun changement de nos manifests. Log : gzip: invalid magic / tar: Child returned status 1 à l'extraction de kube-linter.tar.gz.

Cause : le job téléchargeait le binaire via curl -sSL .../releases/latest/download/kube-linter-linux.tar.gz. Deux défauts cumulés :

1. curl sans -f : sur une réponse HTTP d'erreur transitoire (hoquet GitHub/réseau), curl ne sort pas en erreur, il sauve le corps (HTML d'erreur) dans le .tar.gz. tar plante ensuite sur un fichier qui n'est pas un gzip → message obscur, vraie cause masquée (cf. INC-044 « lire le bon signal »).
2. latest non pinné : non reproductible. Un bump de kube-linter peut introduire de nouvelles règles qui rendraient develop rouge sans changement de notre part.

Correctif (#92, ADR 005 §8) :

• Version pinnée KUBE_LINTER_VERSION: v0.8.3 (= ce que latest servait déjà, version en usage depuis #83 → aucun changement de comportement). URL releases/download/${KUBE_LINTER_VERSION}/....
• curl durci : curl -fsSL --retry 3 --retry-delay 2 --retry-connrefused. Le -f fait échouer proprement sur une erreur HTTP ; --retry encaisse le hoquet transitoire (la cause vécue).

Déblocage immédiat : retry du job kube-linter-scan (l'URL refonctionnait), le pipeline a repris build → promote → pages.

Leçon : un outil téléchargé en latest au runtime est une dépendance externe non pinnée, exactement ce que combat l'ADR 005 §8. Tout curl qui alimente un tar/install doit porter -f (échouer sur erreur HTTP) et --retry (tolérer le transitoire).

#95 — patch de 4 CVE HIGH Python + arbitrage starlette/instrumentator (2026-06-16)

Symptôme : trivy-image-scan rouge sur la branche de !168 (alerting), sans rapport avec son contenu. La base de vulnérabilités Trivy s'était enrichie depuis le dernier build et révélait 4 CVE HIGH fixables dans des dépendances Python (même mécanique que #71 openssl) :

Dépendance	Type	Installé → Fix	CVE
PyJWT	directe	2.12.1 → 2.13.0	CVE-2026-48526 (auth bypass JWT forgé)
python-multipart	directe	0.0.28 → 0.0.32	CVE-2026-53539 (DoS querystring)
starlette	transitive (via fastapi)	1.0.0 → 1.3.1	CVE-2026-48818 (SSRF/NTLM StaticFiles), CVE-2026-54283 (DoS form)

Le piège : PyJWT et python-multipart se patchent seuls (deps directes). Mais starlette 1.3.1 exige fastapi 0.137, et fastapi 0.137 + starlette 1.3 cassent la dernière version de prometheus-fastapi-instrumentator (8.0.0) : '_IncludedRouter' object has no attribute 'path' (starlette 1.3 a introduit un type de route que l'instrumentator ne sait pas parser). Bumper starlette = perdre /metrics (#73, milestone Observabilité). Aucune version plus récente de l'instrumentator n'existe.

Décision (patch partiel + ignore justifié) :

• Patcher PyJWT (la plus sérieuse : l'app fait de l'auth JWT) et python-multipart, via pip-compile --upgrade-package ciblé (diff de 2 lignes, fastapi/starlette intacts → instrumentator préservé).
• Accepter temporairement les 2 CVE starlette dans .trivyignore, après analyse d'exploitabilité :
• CVE-2026-48818 : non exploitable ici (l'app n'utilise ni StaticFiles ni mount()).
• CVE-2026-54283 : exposition limitée au /login (OAuth2PasswordRequestForm), DoS CPU uniquement, pas de fuite/RCE.
• Tracer la dette : issue #96 (bump starlette quand l'instrumentator supporte starlette ≥ 1.3, ou remplacement de la lib de métriques) + retrait des 2 entrées .trivyignore à ce moment.

Validation (offline, méthode projet) : build + Trivy local (--ignore-unfixed --ignorefile) → 0 CVE fixable ; 39 tests verts (fastapi/starlette inchangés → instrumentator OK) ; pip check propre.

Leçon : un correctif de sécurité peut être bloqué par une incompatibilité transitive (ici une lib d'observabilité non maintenue au rythme de starlette). Plutôt qu'un .trivyignore aveugle, la bonne démarche est : (1) isoler ce qui se patche sans casser (PyJWT, python-multipart), (2) analyser l'exploitabilité réelle du reste (le code path existe-t-il ?), (3) accepter le risque résiduel de façon documentée et tracée (justification par CVE + issue de revue). Un HIGH « fixable » ignoré n'est défendable qu'avec cette analyse, pas par défaut.

#68 — SBOM CycloneDX (2026-06-16)

Quoi : génération d'un SBOM CycloneDX de l'image à chaque build, intégrée au job trivy-image-scan (trivy image --format cyclonedx), exposé en artifact (reports:cyclonedx + paths).

Choix d'implémentation : pas de job dédié. L'image candidate est déjà pull et le cache de la base Trivy déjà chaud → une invocation de plus, zéro job supplémentaire, et le SBOM porte exactement sur l'image scannée/promue. Inventaire pur (ni --exit-code ni --severity) : ne fait jamais échouer le pipeline.

Limite tier : la Dependency List UI qui consomme reports:cyclonedx est Ultimate-only. En Free, la valeur est l'artifact SBOM (téléchargeable, conservable, base d'un futur scan VEX / vuln management continu). Détail ADR 005 §9.

---

#80 — Migration VPC CNI → Cilium (overlay, eBPF) (2026-06-18)

Quoi : remplacement du VPC CNI d'AWS par Cilium en mode overlay VXLAN (ipam: cluster-pool, pod CIDR 10.42.0.0/16 hors VPC), avec kubeProxyReplacement eBPF (suppression de kube-proxy) et Hubble + Hubble UI (observabilité réseau interne). Rend la Prefix Delegation #79 obsolète (l'overlay affranchit la densité du plafond ENI). ADR 019, guide comprendre/cilium.md.

Ordre de boot (le point dur) : un managed node group EKS exige des nodes Ready, et ArgoCD ne peut pas poser Cilium (il a lui-même besoin d'un CNI). On distingue le composant vpc-cni (DaemonSet aws-node, installé par défaut par EKS) de l'addon managé : on retire la gestion managée (ressource Terraform aws_eks_addon.vpc_cni), le composant reste en self-managed et amène les nodes Ready au boot. Cilium est ensuite posé en premier par l'amorce Ansible, puis cutover : suppression d'aws-node + kube-proxy (self-managed → non recréés), flush des iptables résiduelles de kube-proxy (DaemonSet one-shot), restart de coredns (reprend une IP overlay).

Pourquoi self-managed et pas l'addon managé : un addon managé est réconcilié par un contrôleur EKS qui recréerait aws-node après suppression → conflit avec Cilium.

Conservé : launch template maxPods: 110 (désormais servi par l'overlay Cilium), AmazonEKS_CNI_Policy (le vpc-cni self-managed s'en sert à l'amorce), NetworkPolicy standard allow-fastapi (#55, Cilium enforce les NetworkPolicy K8s).

Validation : hors infra tfsec 0 HIGH, terraform fmt, ansible --syntax-check, helm template cilium (values rendues). Validé LIVE le 2026-06-18 sur un aws-start from-scratch : plus d'aws-node/kube-proxy, coredns en 10.42.x, kubeProxyReplacement: True, DNS OK, NetworkPolicy allow-fastapi négatif (egress 80 → Network unreachable) + positif (/healthz/ready 200) prouvant l'enforcement Cilium sans addon managé, Hubble UI/relay Running, api.devopsyouss.com → 200, ArgoCD 6/6 Synced/Healthy, ESO SecretSynced, observabilité debout. Deux pièges levés en cours de route avant d'y arriver : INC-058 (webhooks d'admission) puis INC-059 (install ArgoCD). #80 fermée.

INC-058 : webhooks d'admission injoignables sous overlay Cilium (2026-06-18)

Quoi : à la première validation live de la migration Cilium (#80), l'amorce Ansible a échoué sur Install cert-manager (failed post-install: timed out, le startupapicheck ne joint pas le webhook) puis sur la création du ClusterIssuer (Address is not allowed). Le cutover réseau lui-même était sain (DNS, kubeProxyReplacement, Hubble validés).

Cause racine : sous Cilium overlay (pods en 10.42.x, hors VPC), le control plane EKS managé (ses ENI vivent dans le VPC 10.0.x, il ne participe pas à l'overlay VXLAN) ne sait pas router vers une IP de pod overlay. Tout webhook d'admission self-hosted dont le pod a une IP 10.42.x devient donc injoignable depuis l'API server. Avec failurePolicy: Fail, l'appel échoue et bloque l'opération (Address is not allowed).

Cartographie des webhooks (qui casse, qui non) :

Webhook	failurePolicy	Touché ?
cert-manager-webhook	Fail	❌ oui (corrigé)
ESO externalsecret / secretstore-validate	Fail	❌ oui (corrigé)
envoy-gateway-topology-injector	Ignore	✅ non (no-op si injoignable)
vpc-resource-*, pod-identity-webhook	—	✅ non (managés EKS, hors overlay)

Fix : passer les webhooks impactés en hostNetwork: true → le pod prend l'IP du node (10.0.x, dans le VPC), de nouveau routable par le control plane. Câblé dans ansible/bootstrap.yml (values Helm) :

• cert-manager : webhook.hostNetwork: true + webhook.securePort: 10260 (10250 = conflit kubelet sur le réseau du node).
• ESO : webhook.hostNetwork: true + webhook.port: 10261. Le cluster est mono-node : les deux webhooks bindent le même réseau de node, donc deux ports distincts obligatoires (et tous deux hors du 10250 du kubelet).

Validé live le 2026-06-18 (MR !178) : au re-run from-scratch, les deux pods webhook portent bien l'IP du node (10.0.3.89), l'amorce passe cert-manager + ClusterIssuer + ESO sans Address is not allowed, et les ExternalSecrets sont SecretSynced.

Pourquoi pas un patch live : le fix testé live en helm upgrade --set ne survit pas, car la tâche Ansible repose le chart avec --reset-values (le helm du module reset les values non déclarées) → le fix doit vivre dans le playbook. Piège helm noté au passage : --reuse-values + chart latest → nil pointer networkPolicy.enabled ; épingler la version (v1.16.2).

Leçon : un overlay non-natif sur control plane managé qu'on ne contrôle pas (EKS) rompt le routage control-plane → pod. Tout composant que l'API server doit joindre en retour (webhooks d'admission, conversion, agrégation d'API) doit être en hostNetwork ou exposé par un Service routable côté VPC. Ce n'est pas une question de version K8s (vrai en 1.32 comme en 1.34), c'est du routage réseau. Même classe que INC-055/INC-046 : « configuré ≠ joignable au runtime », la preuve c'est le comportement live.

INC-059 : install ArgoCD bloquée par une course de helm --wait (2026-06-18)

Quoi : une fois le trou des webhooks (INC-058) franchi, l'amorce est allée jusqu'à Install ArgoCD et a échoué : Error: services "argocd-applicationset-controller" not found. L'install helm était en --wait.

Cause : course connue du chart argo-cd avec helm --wait. Helm applique les manifests puis attend que chaque ressource soit prête ; il interroge le Service argocd-applicationset-controller avant qu'il soit enregistré dans l'API, reçoit NotFound et abandonne (sur un NotFound, helm ne retente pas, contrairement à un « pas encore Ready »). Rendu plus probable par un cluster fraîchement booté (API brièvement lente juste après le cutover Cilium + restart de coredns). Sans rapport avec Cilium (vérification API, pas datapath) ni avec le teardown (erreur helm propre, pas une coupure de connexion).

Fix : wait: false sur la tâche Install ArgoCD. On ne délègue plus la disponibilité à helm : la tâche Wait for ArgoCD server pod (k8s_info, condition Ready) qui suit la gère déjà, exactement comme pour les autres composants de l'amorce. La séquence (root-app appliqué après que le serveur ArgoCD soit Ready) est préservée.

Validé live le 2026-06-18 (MR !179) : au re-run from-scratch, l'amorce passe Install ArgoCD puis pose le root-app ; les 6 Applications ressortent Synced/Healthy.

Leçon : helm --wait traite un NotFound transitoire comme un échec définitif. Pour une ressource créée en parallèle sur un cluster cold-boot, préférer un gate de disponibilité idempotent et patient (k8s_info wait_condition Ready) plutôt que le --wait du chart. Suivi (hors live) : ajouter un resource_group aux jobs infra pour interdire tout chevauchement d'un pipeline start avec le destroy de 20h.