- Shipped
- September 4, 2026 at 8:39 PM UTC
- Author
- Kamo
- Commit
- 6aba8e8
replicas 1 -> 2. This service runs no @Scheduled work and binds no exclusive NATS durable, so a second pod duplicates nothing — it is stateless request serving, and the only thing keeping it at one replica was that nothing had raised the number. At one replica maxSurge hides the exposure during a clean deploy and nowhere else: an OOM kill, a failed liveness probe or a node drain took the capability out entirely for the 59-79 seconds a Spring context takes to boot. A PodDisruptionBudget in KlusterServices now makes a drain wait.