À 10:46Z, la rotation des identifiants de base de Plausible crée une révision, placée sur pi2. Elle est disponible à 10:49Z.
Depuis 11:08Z, le conteneur plausible est en CrashLoopBackOff : 13 redémarrages en 30 min, code 137.
Il est tué par la sonde de vivacité (failed liveness probe, will be restarted) environ 56 s après chaque départ, sans une ligne de journal.
Le chart pascaliske/plausible 2.0.0 écrit ses deux sondes sur /api/health avec les défauts de Kubernetes : délai 1 s, 3 échecs, aucune sonde de démarrage.
Hors cause, relevé : ClickHouse sain (0 erreur d'E/S), init db migrate en code 0, et la base accepte les connexions.
Accord du fondateur : « Les deux : un délai de démarrage patient et éviter pi2 ».
Ce que fait la PR (deux blocs, rien d'autre)
1. Une startupProbe patiente, même forme que Loki (#45)
startupProbe:httpGet:{path:/api/health, port:http }periodSeconds:10failureThreshold:60# 10 min pour démarrer, puis on abandonnetimeoutSeconds:5
Le chart n'expose pas les sondes dans ses valeurs. Elle est donc posée par un patch JSON dans plausible/kustomization.yaml, sur containers/0, qui est bien plausible (geoip est l'index 1), comme les patchs déjà présents.
La vivacité et la disponibilité restent inchangées. Elles ne prennent le relais qu'une fois le démarrage acquis.
2. Une affinité qui écarte pi2, même forme que ClickHouse (#54)
c'est la plus simple : une seule règle, identique à MinIO (#50), Prometheus (#51) et ClickHouse (#54) ;
elle ne bloque pas le placement si un nœud tombe : pi1 ou pi3 reste éligible. Elle ne bloquerait que si pi1 et pi3 tombaient, et pi1 porte le plan de contrôle ;
une simple préférence n'aurait pas garanti de quitter pi2, qui est le nœud où la panne se produit.
Rendu avant/après
kubectl kustomize --enable-helm plausible/, dépendances construites dans une copie. Le diff du rendu complet ne porte que ces deux blocs du Deployment plausible :
## Cause (tools#53, constat du 2026-09-15)
- À 10:46Z, la rotation des identifiants de base de Plausible crée une révision, placée sur **pi2**. Elle est disponible à 10:49Z.
- Depuis **11:08Z**, le conteneur `plausible` est en `CrashLoopBackOff` : 13 redémarrages en 30 min, code **137**.
- Il est tué par la sonde de vivacité (`failed liveness probe, will be restarted`) environ 56 s après chaque départ, **sans une ligne de journal**.
- Le chart `pascaliske/plausible` 2.0.0 écrit ses deux sondes sur `/api/health` avec les défauts de Kubernetes : **délai 1 s, 3 échecs, aucune sonde de démarrage**.
- Hors cause, relevé : ClickHouse sain (0 erreur d'E/S), init `db migrate` en code 0, et la base accepte les connexions.
Accord du fondateur : « Les deux : un délai de démarrage patient et éviter pi2 ».
## Ce que fait la PR (deux blocs, rien d'autre)
### 1. Une `startupProbe` patiente, même forme que Loki (#45)
```yaml
startupProbe:
httpGet: { path: /api/health, port: http }
periodSeconds: 10
failureThreshold: 60 # 10 min pour démarrer, puis on abandonne
timeoutSeconds: 5
```
- Le chart **n'expose pas les sondes dans ses valeurs**. Elle est donc posée par un patch JSON dans `plausible/kustomization.yaml`, sur `containers/0`, qui est bien `plausible` (`geoip` est l'index 1), comme les patchs déjà présents.
- La vivacité et la disponibilité restent **inchangées**. Elles ne prennent le relais qu'une fois le démarrage acquis.
### 2. Une affinité qui écarte pi2, même forme que ClickHouse (#54)
- `plausible/plausibleValues.yaml` → `affinity.nodeAffinity` : **exclusion requise `kubernetes.io/hostname NotIn [pi2]`**, sans préférence.
- **Pourquoi cette forme** :
- c'est la plus simple : une seule règle, identique à MinIO (#50), Prometheus (#51) et ClickHouse (#54) ;
- elle **ne bloque pas le placement si un nœud tombe** : pi1 ou pi3 reste éligible. Elle ne bloquerait que si pi1 **et** pi3 tombaient, et pi1 porte le plan de contrôle ;
- une simple préférence n'aurait pas garanti de quitter pi2, qui est le nœud où la panne se produit.
## Rendu avant/après
`kubectl kustomize --enable-helm plausible/`, dépendances construites dans une copie. Le diff du rendu complet ne porte **que** ces deux blocs du Deployment `plausible` :
```
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: kubernetes.io/hostname
+ operator: NotIn
+ values:
+ - pi2
…
+ startupProbe:
+ failureThreshold: 60
+ httpGet:
+ path: /api/health
+ port: http
+ periodSeconds: 10
+ timeoutSeconds: 5
```
Relevé en passant : les sondes vivantes du Deployment sont identiques au rendu « avant » (seuls les défauts de l'API diffèrent).
## Ce qu'elle ne fait pas
- Elle ne change ni le délai (1 s) ni les seuils de la vivacité et de la disponibilité.
- Elle ne force aucune synchronisation ArgoCD.
- Si Plausible boucle encore **ailleurs que sur pi2**, l'hypothèse de lenteur est fausse : on s'arrête et on rapporte, sans autre remède.
Refs arcodange-org/tools#53
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Le 2026-09-15, la révision créée par la rotation de ses identifiants de
base a été placée sur pi2. Depuis 11:08Z, le conteneur était tué par la
sonde de vivacité (délai 1 s, 3 échecs, aucune sonde de démarrage) ~56 s
après chaque départ, code 137, sans une ligne de journal.
- une startupProbe patiente sur /api/health (10 min, délai 5 s), posée par
patch kustomize : le chart pascaliske 2.0.0 n'expose pas les sondes ;
- une affinité requise NotIn [pi2], même forme que ClickHouse (#54).
Rendu kustomize --enable-helm avant/après : seuls ces deux blocs changent.
Refs arcodange-org/tools#53
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cause (tools#53, constat du 2026-09-15)
plausibleest enCrashLoopBackOff: 13 redémarrages en 30 min, code 137.failed liveness probe, will be restarted) environ 56 s après chaque départ, sans une ligne de journal.pascaliske/plausible2.0.0 écrit ses deux sondes sur/api/healthavec les défauts de Kubernetes : délai 1 s, 3 échecs, aucune sonde de démarrage.db migrateen code 0, et la base accepte les connexions.Accord du fondateur : « Les deux : un délai de démarrage patient et éviter pi2 ».
Ce que fait la PR (deux blocs, rien d'autre)
1. Une
startupProbepatiente, même forme que Loki (#45)plausible/kustomization.yaml, surcontainers/0, qui est bienplausible(geoipest l'index 1), comme les patchs déjà présents.2. Une affinité qui écarte pi2, même forme que ClickHouse (#54)
plausible/plausibleValues.yaml→affinity.nodeAffinity: exclusion requisekubernetes.io/hostname NotIn [pi2], sans préférence.Rendu avant/après
kubectl kustomize --enable-helm plausible/, dépendances construites dans une copie. Le diff du rendu complet ne porte que ces deux blocs du Deploymentplausible:Relevé en passant : les sondes vivantes du Deployment sont identiques au rendu « avant » (seuls les défauts de l'API diffèrent).
Ce qu'elle ne fait pas
Refs arcodange-org/tools#53
🤖 Generated with Claude Code