Kubernetes interview question · Most asked
Liveness, readiness and startup probes: how do you configure them correctly?
Summary
Readiness decides whether a pod receives traffic; liveness decides whether the container is restarted; a startup probe holds off the other two until a slow-starting app is up. Readiness may reflect whether the instance can serve; liveness should only detect a stuck process and must not depend on external systems.
Longer Answer
If liveness checks the database, a database blip restarts every pod at once and turns a partial outage into a full one. Other tips: give probes realistic timeouts and failure thresholds; use a startup probe instead of a huge initialDelaySeconds; make readiness fail during graceful shutdown so the pod leaves the endpoints; and keep probe endpoints cheap.
Missing readiness probes mean pods receive traffic before they can serve, causing errors during every rollout.
Key Points
- Readiness = traffic; liveness = restart; startup = slow boot.
- No dependency checks in liveness.
- Realistic thresholds; startup probe for slow apps.
- Missing readiness = errors during rollouts.
More most-asked Kubernetes questions
- ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?
- How does the scheduler place pods? Explain resource requests, node affinity, taints and tolerations.
- Describe the Kubernetes architecture: what runs on the control plane and what runs on the nodes?
- How do rolling updates work in a Deployment, and how do you roll back?
- Explain the Service types: ClusterIP, NodePort, LoadBalancer, ExternalName and headless.
- What happens, step by step, when you run kubectl apply for a Deployment?
- Deployment, StatefulSet, DaemonSet, Job and CronJob: when do you use each?
- What is the difference between resource requests and limits, and what are the QoS classes?