- Ya
- 7 Agosti 2026, 07:48 UTC
- Mwandishi
- Kamo
- Ahadi ya
- e853649
Same fault as embedding-model, found by auditing every hostPath volume in the repo. A hostPath is node-local and nothing replicates it, so an unpinned pod can be scheduled where its data is not. All four moved or were at risk of moving when k3m1 joined. postgres-analytics is the one that mattered: DirectoryOrCreate does not fail on a missing path, it creates an empty one, and postgres would have run initdb into it. A reschedule would not have crashed -- it would have served analytics an empty analytics history while the real 67MB stayed on k1m1. Verified intact after pinning: 18 tables, 2655 events. qdrant is pinned to k3m1 rather than k1m1 because that is where its live data is. It moved when k3m1 joined, silently got a fresh store, and the kb collection has been written there since; k1m1 still holds a March snapshot, so sending the pod "home" would have quietly served four-month-old vectors. It also switches to Recreate: qdrant holds an exclusive WAL lock, so a surge pod sharing the directory panics with `Can't init WAL: WouldBlock` and the rollout could never finish. That was latent -- any image bump would have hit it. bergamot and libretranslate only re-downloaded their models on the new node, which is why nobody noticed; libretranslate's own comment claimed both replicas were on k1m1, and the pin makes that true again instead of leaving 9.7GB duplicated on k3m1.