fix(redis) — il mourait toutes les 90 s, et c'est le .fr qui tombait

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

redis/values.yaml

@@ -140,13 +140,36 @@ redis: &redis_config
     runAsUser: 999
 
   # -- Compute resources used by the container. More info [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
-  resources: {}
-    # limits:
-    #   cpu: 100m
-    #   memory: 128Mi
-    # requests:
-    #   cpu: 100m
-    #   memory: 128Mi
+  #
+  # ⚠ CE N'EST PAS DU CONFORT — c'est ce qui empêche Redis de mourir en boucle.
+  #
+  # Le sous-chart FIGE ses sondes à `timeoutSeconds: 1` sur `redis-cli ping`, et
+  # n'expose aucune valeur pour les surcharger. Sur ce matériel (Raspberry Pi),
+  # un conteneur SANS réservation tombe dans la classe QoS `BestEffort` : il est
+  # le premier affamé quand le nœud est chargé, et le simple lancement de
+  # `redis-cli` y dépasse la seconde.
+  #
+  # Mesuré le 2026-07-29 sur `redis-0` : « Liveness probe failed: command timed
+  # out: "redis-cli ping" timed out after 1s » **836 fois en 23 jours**, 135
+  # redémarrages, le conteneur tué par SIGTERM après ~90 s de vie à chaque tour.
+  #
+  # ⚠ CE QUE ÇA CASSAIT, ET QUI N'AVAIT RIEN À VOIR AVEC REDIS EN APPARENCE : le
+  # plugin crowdsec de Traefik utilise ce Redis comme cache de décisions. Cache
+  # injoignable ⇒ `isCrowdsecStreamHealthy:false` ⇒ le plugin REFUSE PAR DÉFAUT
+  # tout client non listé dans `clientTrustedIPs` ⇒ **403, corps vide, sur
+  # `kadans.arcodange.fr` et `gitea.arcodange.fr`**, pendant que les hôtes qui ne
+  # portent pas ce middleware répondaient normalement. Le symptôme ne nomme ni
+  # Redis, ni crowdsec, ni la sonde — il ressemble à un bannissement d'IP, et
+  # c'est par là qu'on cherche d'abord.
+  #
+  # Une 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.
+  resources:
+    requests:
+      cpu: 50m
+      memory: 64Mi
+    limits:
+      memory: 256Mi
 
   # -- Pod-level affinity. More info [here](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling).
   affinity: {}