fix(crowdsec) — nom de machine stable : 594 LAPI fantômes s'étaient entassées en base #56
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  arcodangeandClaude Opus 5
|
6404570bd7 |
fix(crowdsec) — nom de machine stable : 594 LAPI fantômes s'étaient entassées en base
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Detect changed charts (pull_request) Successful in 21s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts alloy (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts loki (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Successful in 51s
`cscli machines list` renvoyait 617 lignes le 2026-09-20, dont 594
`crowdsec-lapi-*` remontant au 2025-12-05. Une seule LAPI tourne à la fois :
593 étaient mortes.
Le mécanisme n'est pas celui qu'on croit. Ce ne sont PAS des redémarrages — un
redémarrage garde le nom du pod. Mesuré : 571 hashes de ReplicaSet DISTINCTS
pour 594 enregistrements, soit un pod template qui change presque à chaque fois.
Ce qui le change, c'est le `rolloutRestartTargets` du VaultDynamicSecret
(crowdsec/templates/vaultdynamicsecret.yaml) : à chaque rotation de
l'identifiant Postgres, VSO force un rollout → nouveau pod template → nouveau
hash de ReplicaSet → nouveau nom de pod. Soit 2,05 par jour sur 290 jours.
Le chart amont code en dur `CUSTOM_HOSTNAME` sur `metadata.name`, et
l'entrypoint enregistre la LAPI sous ce nom :
si .login (fichier d'identifiants) == CUSTOM_HOSTNAME et machine existante
→ « Local agent already registered », rien à faire
sinon
→ cscli machines delete <CUSTOM_HOSTNAME> ; cscli machines add
Le `delete` ne porte que sur le nom COURANT. L'enregistrement du pod précédent
n'est jamais supprimé — d'où l'entassement, sans borne.
Ça compte parce que la LAPI stocke son état dans le PostgreSQL externe de pi2,
à `max_connections=100`, celui-là même qui a refusé des connexions le 2026-09-20
(SQLSTATE 53300) et fait crasher la LAPI trois fois.
Correctif : fixer `CUSTOM_HOSTNAME` à `crowdsec-lapi`. Le premier démarrage fait
delete+add sur ce nom, tous les suivants tombent sur « already registered » et
n'écrivent plus rien. Le fichier d'identifiants survit aux redémarrages
(/etc/crowdsec est un lien vers le PVC crowdsec-config, vérifié sur le pod),
donc la comparaison sur `.login` tient dans le temps.
⚠ L'entrée doit vivre dans `lapi.env` : le chart émet sa propre définition de
CUSTOM_HOSTNAME AVANT d'injecter `.Values.lapi.env`, et Kubernetes retient la
DERNIÈRE occurrence en cas de doublon. Vérifié deux fois : `helm template` place
bien la nôtre en position 7 contre 5 pour celle du chart, et un pod de test avec
les deux définitions a renvoyé `crowdsec-lapi`. `kubectl apply` avertit
« hides previous definition » — c'est attendu.
⚠ Ne pas « corriger » en retirant le rolloutRestartTargets : les identifiants
arrivent par secretKeyRef, qui ne se recharge pas à chaud. Sans rollout, la LAPI
garderait des identifiants révoqués par Vault.
Les 614 enregistrements orphelins ont été supprimés à la main en amont de ce
correctif (`cscli machines delete`, par lots), en excluant explicitement les
trois pods vivants. ⚠ `cscli machines prune` aurait été le mauvais outil : il
filtre sur le heartbeat, or la LAPI n'en émet pas (DISABLE_AGENT=true) — elle
aurait été supprimée avec les morts.
Co-Authored-By: Claude Opus 5 <[email protected]>
|