arcodangeandClaude Opus 5
f53c3adb7d
Symptôme observé : `kadans.arcodange.fr` et `gitea.arcodange.fr` en 403, corps vide, depuis n'importe quel client extérieur — pendant que `arcodange.fr` et `www` répondaient 200. Ça ressemble à un bannissement d'IP. Ça n'en était pas un. La chaîne, remontée de bout en bout : 1. Le sous-chart fige ses sondes à `timeoutSeconds: 1` sur `redis-cli ping` et n'expose aucune valeur pour les surcharger. 2. Sans réservation de ressources, le conteneur est en QoS `BestEffort` : sur un Raspberry Pi chargé, lancer `redis-cli` dépasse la seconde. 3. « Liveness probe failed: command timed out after 1s » 836 fois en 23 jours, 135 redémarrages, SIGTERM après ~90 s de vie à chaque tour. 4. Le plugin crowdsec de Traefik utilise ce Redis comme cache de décisions. Cache injoignable ⇒ `isCrowdsecStreamHealthy:false` ⇒ refus par défaut de tout client absent de `clientTrustedIPs` ⇒ le 403. D'où le motif trompeur : seuls les hôtes portant le middleware crowdsec tombaient, et depuis le LAN (IP de confiance) tout paraissait sain — l'origine répondait 401, son défi d'authentification normal. Trois fausses pistes en sont sorties : Cloudflare, un bannissement crowdsec, une règle de pare-feu. Aucune n'était la bonne, et `cscli decisions list` disait `isBanned:false` du début à la fin. La réservation fait passer le conteneur en `Burstable` et lui garantit sa part. Les limites restent larges : Redis n'est pas ce qui sature ce nœud. ⚠ Ce commit ne corrige PAS la sonde elle-même — elle reste à 1 s, et elle reste inatteignable depuis les valeurs. Si le clignotement revient malgré la réservation, il faudra un patch Kustomize au niveau de l'Application ArgoCD, ou abandonner ce sous-chart. Une vérification en production a été appliquée à chaud (`timeoutSeconds: 5`, `failureThreshold: 6`) pour rétablir l'accès immédiatement, mais `selfHeal: true` la ré-écrasera : elle n'est pas la correction, ce commit l'est. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01GdUCA5Uz8QyMwa2P4Pg2hK
Run kubectl port-forward -n tools svc/redis 6379:6379 and launch Redis Insights