Zero-downtime deploys on Kubernetes mean users never see failed requests while running pods are replaced with a new image. That requires at least two healthy replicas during the swap, a rolling update that creates before it destroys, readiness probes that gate traffic, and on multi-node clusters a Pod Disruption Budget so maintenance does not drain every pod at once. On a single-node cluster you can minimize blips, but true zero downtime needs independent failure domains—one node cannot provide that.
DarDevOps applies these patterns on internal stacks—Twenty CRM, Listmonk, sync workers on dardev-vps—and on client clusters across MENA. The goal is a deploy contract your CI pipeline and Ingress can enforce, not a magic kubectl flag.
What zero-downtime actually means
Zero downtime is an availability target during rollout, not immunity from all failures. Kubernetes removes endpoints from a Service when readiness fails, stopping traffic to pods that are starting or shutting down—if probes are configured correctly. A deploy is zero-downtime when every request during the rollout is served by a pod that passes readiness for the whole window.
That breaks when replica count is one, when maxUnavailable allows all pods to terminate before replacements are ready, or when readiness returns 200 before the app can serve real traffic. Staging must mirror production probe timings—see staging environments that match production before trusting a rolling strategy in prod.
Single-node vs multi-node
A single-node cluster runs the control plane and all workloads on one machine. Rolling updates still work if CPU and memory headroom exist: Kubernetes can start a new pod before terminating the old one. But both pods share one kernel, disk, and network path—node maintenance or OOM kills take everything offline.
- Single-node: cheaper ops; accept brief blips or schedule maintenance windows
- Multi-node: spread replicas across failure domains; PDBs and anti-affinity matter
- Two small nodes often beat one large node for deploy safety at similar cost
Teams migrating from Docker Compose often run one replica per service on day one. That is fine for tolerant internal tools; it is not zero-downtime for customer APIs. Our compose-to-kubernetes migration path includes an explicit milestone: second replica plus rolling strategy before calling production hardened.
Rolling updates
Deployment strategy RollingUpdate is the right default for stateless HTTP services. maxSurge controls extra pods above desired count; maxUnavailable controls how many may be down simultaneously. With two replicas, start with maxSurge: 1 and maxUnavailable: 0—Kubernetes brings up a new pod, waits for readiness, adds it to Service endpoints, then terminates an old pod.
With three or more replicas you can set maxUnavailable: 1 to speed rollouts while keeping quorum. StatefulSets roll one pod at a time by default, which protects data but slows deploys.
GitLab CI should run kubectl rollout status deployment/myapp -n production --timeout=5m after apply. Our GitLab CI to Kubernetes guide covers namespace-scoped tokens and rollout gates.
Pod Disruption Budgets (PDBs)
Rolling updates are voluntary disruption you trigger. PDBs protect against voluntary evictions—node drains, cluster upgrades, autoscaler scale-down. minAvailable: 1 tells the eviction API it cannot remove so many pods that your budget is violated. PDB selectors must match Deployment pod template labels exactly. PDBs do not block hard node failure—design for replica spread across nodes.
On single-node clusters PDBs still serialize kubectl drain. On multi-node clusters PDBs plus podAntiAffinity reduce the chance that a rolling update and a node drain collide into zero ready endpoints.
Probes and graceful shutdown
Readiness gates Service endpoints; liveness restarts stuck containers. Size initialDelaySeconds for your real startup curve. Liveness should not hit the same dependency-heavy path as readiness or a slow database causes restart loops during deploy.
On pod deletion Kubernetes sends SIGTERM, removes endpoints after propagation delay, then waits terminationGracePeriodSeconds. A preStop sleep 5 or app drain hook lets in-flight requests finish after load-balancer deregistration. Five to fifteen seconds of preStop is common for HTTP APIs.
When brief downtime is acceptable
Internal admin UIs and staging can run single-replica Deployments with communicated maintenance windows. Customer-facing APIs should not. When a bad image slips through, kubectl rollout undo beats forward-fixing under fire—see runbook rollback for bad deploy. DarDevOps engagements start with replica count and PDB review before recommending canary controllers; most SME teams reach safe rollouts with two nodes, sensible probes, and CI rollout gates—see dardev.net/products.
Can I get zero-downtime deploys on a single-node cluster?
You can minimize errors with maxSurge: 1, maxUnavailable: 0, and two replicas if the node has capacity—but both pods share one failure domain, so node reboots still cause outage. True independence needs at least two worker nodes.
What rolling update settings for two replicas?
maxSurge: 1, maxUnavailable: 0, readiness probes that reflect real dependencies, and CI running kubectl rollout status with a timeout before marking deploy success.
Do I need a PDB if I use rolling updates?
Yes. Rolling updates control deploy-triggered replacement; PDBs protect against node drains and cluster upgrades. Without a PDB, maintenance can evict all pods at once.
Why do users still see 502 errors during deploy?
Usually readiness too optimistic, missing preStop, maxUnavailable too high for replica count, or Ingress endpoint lag. Reproduce in staging with load during rollout.
How does DarDev run zero-downtime deploys?
Multi-replica Deployments, GitLab CI rollout gates, PDBs on critical tiers, and documented rollback paths—the same DarDevOps patterns we implement for client clusters.
