Kubernetes interview question · Most asked
What is Kubernetes not good at, or when would you avoid it?
Summary
Kubernetes adds substantial operational complexity: networking, security, upgrades, observability and a large ecosystem to learn. For a small team with a few services, a PaaS, serverless functions, or a simpler container service (ECS, Cloud Run, App Runner) often delivers the same outcome with far less work.
Longer Answer
Kubernetes pays off with many services and teams, a need for portability, custom scheduling (GPUs, batch), or a platform team that builds paved roads on top of it. It does not by itself make applications scalable or reliable: stateless design, health checks, graceful shutdown and good observability still matter. A balanced answer shows you have run it and know its costs.
Key Points
- Significant operational overhead.
- Simpler options for small teams.
- Pays off at scale or with platform teams.
- Not a substitute for good app design.
Explanation
What interviewers look for
Pragmatism: an engineer who recommends Kubernetes only where it fits.
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?