Design a zero-downtime Kubernetes Deployment strategy for a stateless microservice

What's really being asked

This question evaluates whether you understand the difference between a pod being running and being ready to serve traffic, and how Kubernetes orchestrates rolling updates safely. It tests your ability to combine declarative rollout configuration with imperative lifecycle hooks and probe semantics to eliminate downtime during deployments.

The full answer

First, the Deployment strategy must be RollingUpdate, not Recreate. For a critical service, set maxSurge to 1 and maxUnavailable to 0 so the cluster creates a new pod before terminating an old one, ensuring total capacity never drops. Second, readiness probes are essential because a pod must pass its readiness check before the Service endpoints controller adds it to the load balancer; without this, traffic hits a container that has started but is not yet initialized. Third, terminationGracePeriodSeconds defines the window between SIGTERM and SIGKILL, giving the application time to finish active requests. A preStop hook that sleeps for a few seconds before SIGTERM arrives is a practical way to let the endpoint removal propagate to load balancers and clients before the container begins draining. Fourth, the application itself must handle SIGTERM gracefully by stopping the HTTP listener and finishing in-flight work.

The mistakes people make

A red flag is omitting readiness probes and relying only on liveness probes, which causes traffic blackholing during startup. Another mistake is setting maxUnavailable above zero for a critical service without explaining the capacity risk; while valid for cost-sensitive batch workloads, it can cause request failures if the remaining pods are overloaded. Candidates also err by ignoring the endpoint propagation delay and assuming SIGTERM alone is sufficient, leading to 502 errors during rollouts.

What usually comes next

Interviewers often ask what happens if a pod ignores SIGTERM, how you would protect a StatefulSet rollout differently, or how to coordinate database schema changes with this deployment. They may also probe whether you would use a service mesh or ingress canary instead of a native rolling update for higher risk releases.

A concrete example

Imagine a stateless API with a 30-second average request latency. You configure maxSurge 1, maxUnavailable 0, a readiness probe on the health endpoint with periodSeconds 5, terminationGracePeriodSeconds 60, and a preStop hook that sleeps 10 seconds. When a new version deploys, Kubernetes spins up a replacement, the readiness probe passes, the old pod receives SIGTERM, the preStop sleep allows the endpoint removal to propagate, and then the application drains its connections before the 60-second grace period expires.