template 0.7.3: releases never leave the Service empty — surge rollout, graceful drain, opt-in HA #17
No reviewers
Labels
No labels
agent-work
agent-working
ultracode
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
open-platform/app-template!17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "zero-downtime-rollout"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Chart:
strategy: RollingUpdate(maxSurge: 1,maxUnavailable: 0) +minReadySeconds: 5replacesRecreate— the new pod starts beside the old one, must pass startup/readiness and stay Ready 5 s, only then is the old pod retired; a pod that never becomes Ready leaves the old one serving and Flux's HelmRelease wait + rollback remediation revert the release.preStop: sleep 5lets the endpoint removal reach Traefik before SIGTERM. Newreplicasvalue (default 1); aPodDisruptionBudget(minAvailable 1) renders only at 2+ so a single replica never blocks a node drain.Server: SIGTERM/SIGINT drain in-flight requests via
app.close(), hard exit at 10 s.Why the RWO
/dataPVC is fine for the overlap: local-path pins the PV to a node, so the surge pod schedules onto the same node (RWO = one node, not one pod), and the template never writes there.The fleet-wide counterpart is the
zero-downtime-rolloutKyverno mutate policy in plat/gitops, which asserts the same strategy on every existing app's next rollout (185 web Deployments wereRecreate). This PR makes the template tell the same truth for apps born from now on.typecheckclean, 37/37 tests.