- Shipped
- 4 Septemba 2026, 20:40 UTC
- Author
- Kamo
- Commit
- dc8b3a3
PodDisruptionBudgets for the 25 Deployments that now genuinely run two replicas. minAvailable: 1 lets a drain evict one pod and wait for its replacement instead of taking a whole node's worth down at once. The kamo namespace had ZERO of these while cluster-services, kamo-universe, ratestack, longhorn-system and kubevirt all had them — the namespace holding production was the one without. Only Deployments actually at two replicas appear. A PDB on a single-replica Deployment is worse than none: minAvailable: 1 against replicas: 1 permits zero disruptions, so it does not protect the workload, it blocks node maintenance forever. README.md says so, and names the deliberate singletons that must never be listed. scripts/audit-deploy-safety.sh fails the deploy if a Deployment in kamo has drifted back to a shape that drops requests during a rollout: no readiness probe, no preStop hook, no minReadySeconds, Recreate without an opt-out, or two replicas with nothing spreading them across nodes. It audits the CLUSTER rather than the manifests. Those settings live in 48 separate repositories with 48 workflows; a per-repo guard would catch a regression earlier, but it is 48 copies to keep in step and any repo that never adopts it is silently exempt. Every one of those manifests ends up here. The trade is that it is a smoke alarm rather than a lock — it reports after the fact, so it prints the whole table and names what drifted rather than just failing. Exemptions are annotations on the Deployment itself, and a reason is mandatory: an exemption without one is a failure. That is what lets the next person tell a deliberate singleton (kamodaemon binds exclusive NATS durables) from something nobody got round to.