Kubernetes · Orchestration under pressure
What are the most common Kubernetes production mistakes?
Short answer
Common failures include missing resource requests, mutable latest tags, absent disruption budgets, single replicas, weak probes and secrets in plain manifests. Each turns a routine event into an outage.
Most Kubernetes incidents are configuration and ownership problems rather than control-plane bugs. The recurring pattern is a workload that looks healthy but cannot tolerate a node drain, a bad image, a traffic spike or a dependency failure.
- No resource requests, so scheduling and autoscaling are blind
- Using latest tags, so rollbacks and reproducibility break
- Running one replica with no PDB, so a drain is an outage
- Liveness probes that check dependencies and restart the fleet
- Secrets committed to Git or injected as environment variables
- No PodDisruptionBudget or no capacity headroom during upgrades
- Ignoring namespace quotas, so one team consumes the cluster
The fix is usually a platform default rather than a one-off patch: admission policies that require requests and limits, image digest pinning, baseline network policies, namespace quotas and a deployment template with probes and disruption budgets. Then exceptions are explicit and reviewable.
kubectl get pods -A --field-selector=status.phase=Pending
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.status.containerStatuses[*].restartCount}{"\n"}{end}'
kubectl get deploy -A -o wide
kubectl get pdb -AFollow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which mistake causes the largest blast radius?
- 2How would you enforce resource requests across teams?
- 3Why is a single replica with a PDB still risky?
- 4What would you fix first in an inherited cluster?
Say it in the interview
The common mistakes are missing requests, floating image tags, single replicas, weak probes, no disruption budgets and secrets in Git. They matter because each one turns a normal event like a drain or a bad release into an outage. I prefer fixing them at the platform level with admission policies, quotas and standard templates rather than relying on review. Then I test drains and node loss to confirm the guardrails actually work.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.