Kubernetes Interview Questions & Answers (2026)
These interviews test your grasp of Kubernetes architecture, API usage, and real‑world operational skills. Demonstrate clear understanding of control plane components, pod lifecycle, networking, storage, and security. Show how you troubleshoot common failures, design resilient clusters, and automate deployments. Emphasize concrete examples, trade‑offs, and best‑practice reasoning to convince interviewers you can manage production workloads.
20 questions · updated Aug 29, 2026
Quick facts
| Typical rounds | Phone screen → Technical deep‑dive → System design → Hands‑on coding |
| Core topics | Control plane, pod lifecycle, networking, storage, RBAC, Helm, troubleshooting |
| Preferred experience | 2‑5 years managing production clusters, CI/CD integration, and cloud‑native tooling |
| Common formats | Scenario‑based questions, whiteboard diagrams, live kubectl demos |
Questions
Beginner
What are the main components of the Kubernetes control plane and what does each do?
The control plane consists of the API server, etcd, controller manager, and scheduler. The API server is the front‑end that validates and persists all cluster state. etcd stores the desired state as a consistent key‑value store. The controller manager runs controllers that reconcile actual state to the desired state, such as the replication controller. The scheduler watches for unscheduled pods and assigns them to nodes based on resource requests, affinity rules, and taints. Interviewers look for a clear mapping of responsibilities and awareness of how these components interact to maintain cluster health.
Explain how a pod's IP address is assigned and how pods communicate within a cluster.
When a pod is created, the kubelet requests an IP from the cluster's network plugin (CNI). The IP is allocated from a node‑local subnet, ensuring each pod gets a unique address. Pods communicate directly via these IPs using the overlay network (e.g., Flannel) or native routing (e.g., Calico). The kube-proxy configures iptables or IPVS rules on each node to route Service ClusterIP traffic to the appropriate pod endpoints, enabling load‑balanced intra‑cluster communication without NAT. Interviewers expect you to mention CNI, pod CIDR, and kube-proxy behavior.
How does Kubernetes implement service discovery and load balancing?
Kubernetes creates a Service object that defines a stable ClusterIP and a set of selector labels. Endpoints controller watches pods matching those labels and updates the Service's endpoint list. kube-proxy on each node programs iptables or IPVS rules so traffic to the Service IP is load‑balanced across the pod IPs. For external access, a LoadBalancer Service triggers cloud provider LB provisioning, while NodePort exposes a static port on each node. Interviewers want you to cover ClusterIP, endpoint resolution, and the role of kube-proxy in balancing traffic.
What is a DaemonSet and when would you use it?
A DaemonSet ensures that a copy of a pod runs on every node (or a subset defined by node selectors). It is ideal for cluster‑wide agents such as log collectors, monitoring daemons, or network plugins that need to run on each node. Unlike Deployments, DaemonSets do not perform rolling updates across replicas; they update pods node‑by‑node. Interviewers look for understanding of scheduling constraints, use cases, and differences from Deployments or ReplicaSets.
What is the purpose of a kubelet and how does it interact with the API server?
The kubelet runs on each node, ensuring that containers defined in pod specs are running and healthy. It watches the API server for pod assignments, pulls container images, creates pods via the container runtime, and reports node status and pod health back to the API server. It also executes liveness and readiness probes. Interviewers want to see that you understand the kubelet's role as the node‑level agent that enforces the desired state.
What is a NodePort service and when would you prefer it over a LoadBalancer?
A NodePort exposes a Service on a static port (30000‑32767) on each node's IP, allowing external traffic to reach the Service without a cloud load balancer. It is useful in on‑prem environments where a cloud LB is unavailable or for debugging. However, it lacks built‑in health checks and may expose the cluster to the internet if not firewalled. Interviewers expect you to compare simplicity, cost, and security implications.
Intermediate
Describe the role of etcd in Kubernetes and how you would back it up safely.
etcd is a distributed, strongly consistent key‑value store that holds the entire cluster state, including objects like Deployments, Services, and ConfigMaps. Because it is the source of truth, loss or corruption can bring a cluster down. Safe backup involves taking a snapshot using `etcdctl snapshot save` while ensuring the cluster is in a quiescent state or using the built‑in snapshot controller. Store snapshots in a secure, off‑site location, rotate them regularly, and test restores on a staging cluster. Interviewers expect you to discuss consistency, snapshotting, and disaster‑recovery procedures.
How does the Kubernetes scheduler decide where to place a pod?
The scheduler evaluates each pending pod against all nodes using a two‑phase process: filtering and scoring. Filtering discards nodes that lack required resources, violate node selectors, taints/tolerations, or affinity rules. Scoring then assigns a rank based on factors like resource balance, pod affinity, and custom policies via plugins. The highest‑scoring node is selected, and the pod is bound via the API server. Interviewers want you to mention the extensible plugin architecture, the importance of resource requests, and how custom policies can influence placement.
What are PodSecurityPolicies and how have they been replaced in newer Kubernetes versions?
PodSecurityPolicies (PSPs) were cluster‑level resources that defined a set of security constraints (e.g., privileged escalation, hostPath usage) which pods had to satisfy. They were enforced via the admission controller and tied to RBAC. Starting with Kubernetes 1.25, PSPs are deprecated in favor of the Pod Security Standards (PSS) implemented through the admission controller `PodSecurity`. PSS provides three predefined levels—privileged, baseline, and restricted—making policy definition simpler and more declarative. Interviewers look for awareness of deprecation timeline and migration steps.
Explain how a RollingUpdate strategy works for Deployments.
A RollingUpdate gradually replaces old ReplicaSet pods with new ones while maintaining the desired replica count. The controller respects `maxUnavailable` (how many pods can be down simultaneously) and `maxSurge` (how many extra pods can be created). It creates new pods, waits for them to become Ready, then scales down old pods. This ensures zero‑downtime deployments if health checks are correct. Interviewers expect you to discuss the parameters, readiness probes, and how the strategy avoids service disruption.
How would you troubleshoot a pod that is stuck in CrashLoopBackOff?
First, run `kubectl describe pod` to view events for OOMKilled, image pull errors, or failed liveness probes. Then inspect logs with `kubectl logs` (add `-p` for previous container). Check the container's exit code and compare it to the Dockerfile CMD. Verify resource limits, environment variables, and ConfigMap mounts. If the issue is transient, increase `restartPolicy` back‑off limits or adjust probes. Finally, consider recreating the pod with a fresh image tag. Interviewers want a systematic approach, covering both Kubernetes and application‑level causes.
Explain the difference between a StatefulSet and a Deployment.
A Deployment manages stateless pods, providing rolling updates and replica scaling without preserving identity. A StatefulSet is for stateful workloads requiring stable network IDs, ordered deployment, and persistent storage. Each pod gets a deterministic name (e.g., web-0) and a stable PersistentVolumeClaim. Scaling respects ordering, and updates can be performed with `OnDelete` or `RollingUpdate` strategies that maintain identity. Interviewers look for the need for stable identities, ordered startup, and storage guarantees.
How does Kubernetes handle secret management and what are best practices?
Secrets are stored as base64‑encoded objects in etcd and mounted into pods as files or environment variables. Best practices include enabling encryption at rest for etcd, using external secret stores (e.g., HashiCorp Vault, AWS Secrets Manager) via the CSI driver, limiting secret access with RBAC, and rotating secrets regularly. Avoid committing secrets to image layers and use `kubectl create secret` with `--dry-run` for reproducibility. Interviewers expect you to discuss encryption, external providers, and RBAC scoping.
How does Kubernetes implement garbage collection for unused resources?
Kubernetes runs a garbage‑collector controller that periodically scans for orphaned objects, such as finished Jobs, terminated Pods, and unused PersistentVolumeClaims. It respects `ttlSecondsAfterFinished` for Jobs and `--terminated-pod-gc-threshold` for Pods. For resources with owner references, it follows cascading deletion rules. This prevents resource bloat and frees cluster capacity. Interviewers look for knowledge of the controller, TTL fields, and how owner references influence cleanup.
Advanced
What is a Service Mesh and when would you introduce one to a Kubernetes environment?
A Service Mesh adds a dedicated data plane (sidecar proxies) and control plane to manage service‑to‑service communication, providing observability, traffic shaping, and security without code changes. You’d introduce a mesh like Istio when you need fine‑grained traffic routing (canary releases), mutual TLS for zero‑trust security, or detailed telemetry across microservices. The trade‑off includes added complexity, resource overhead, and operational learning curve. Interviewers look for justification of benefits versus cost and awareness of mesh components (pilot, envoy, telemetry).
Describe how Horizontal Pod Autoscaler (HPA) works and its limitations.
HPA monitors metrics (CPU, memory, custom) via the Metrics Server and adjusts the replica count of a Deployment based on a target utilization. It calculates the desired replica count using a proportional controller and respects `minReplicas` and `maxReplicas`. Limitations include reliance on accurate metrics, delay due to scaling cooldown periods, inability to scale stateful workloads without careful design, and potential thrashing if metrics fluctuate rapidly. Interviewers expect you to discuss the control loop, metric sources, and practical constraints.
How do you secure inter‑pod communication in a multi‑tenant cluster?
Use network policies to restrict traffic based on namespace, pod selectors, and ports, effectively creating a whitelist. Combine with a CNI that supports policy enforcement (e.g., Calico). Enable mutual TLS via a Service Mesh for encryption and identity verification. Apply RBAC to limit who can create or modify policies. Also isolate workloads using separate namespaces and resource quotas. Interviewers want a layered defense strategy, showing knowledge of network policies, encryption, and RBAC.
What is a Custom Resource Definition (CRD) and how do you use an Operator to manage it?
A CRD extends the Kubernetes API with a new object kind, allowing you to model domain‑specific concepts (e.g., MySQLCluster). An Operator watches these custom resources using a controller (often built with the Operator SDK) and reconciles the desired state by creating native resources (StatefulSets, Services) and handling lifecycle events. This pattern enables automation of complex applications while leveraging Kubernetes primitives. Interviewers assess your grasp of extending the API, controller loops, and the benefits of declarative management.
How would you migrate a legacy monolithic app to Kubernetes with minimal downtime?
First, containerize the app and push images to a registry. Deploy the container as a Deployment behind a Service. Use a Blue/Green strategy: create a new version in a separate namespace, route traffic via an Ingress or Service selector switch, and validate health. Once stable, decommission the old version. Leverage readiness probes to ensure new pods are ready before taking traffic. This approach limits downtime while allowing rollback. Interviewers assess your migration planning, traffic routing, and rollback capabilities.
What are the trade‑offs between using iptables vs IPVS mode in kube-proxy?
iptables mode programs netfilter rules for each Service endpoint, which works well for small clusters but can become performance‑limited with many services due to rule count. IPVS mode uses Linux Virtual Server to create a single virtual IP per Service and load‑balances to endpoints via hash tables, offering higher throughput and lower latency, especially at scale. However, IPVS requires kernel modules and may have compatibility issues with some CNIs. Interviewers expect you to discuss scalability, performance, and operational considerations.
Common mistakes
- Confusing Deployment replicas with pod replicas and ignoring pod lifecycle nuances.
- Omitting resource limits, leading to OOMKilled pods during scaling tests.
- Relying solely on default network policies, which leaves inter‑namespace traffic unrestricted.
- Skipping etcd encryption and backup, exposing the cluster to data loss.
- Using iptables mode in large clusters without measuring performance impact.
Study plan
- Review control‑plane components and their APIs; draw diagrams to internalize interactions.
- Practice kubectl commands for pods, services, deployments, and troubleshooting scenarios.
- Implement a small multi‑node cluster with Kind; experiment with network policies and HPA.
- Create a CRD and a simple Operator; study reconciliation loops and error handling.
- Simulate production failures (node loss, etcd snapshot restore) to build confidence in disaster recovery.
FAQ
How many years of Kubernetes experience do most employers expect?
Most mid‑level roles ask for 2‑5 years of hands‑on production experience, including cluster provisioning, CI/CD integration, and troubleshooting.
Is it necessary to know Helm for a Kubernetes interview?
Yes, Helm is the de‑facto package manager; interviewers often ask about chart structure, templating, and release management.
Can I use Docker Desktop for interview practice?
Docker Desktop provides a single‑node Kubernetes cluster, which is fine for basic concepts, but practice on multi‑node setups (Kind or Minikube) to cover scheduling and networking.
What is the difference between a Service and an Ingress?
A Service provides stable networking within the cluster, while an Ingress adds HTTP routing rules and optional TLS termination, typically backed by a load balancer.
Do I need to know cloud‑specific integrations like EKS or GKE?
Understanding how managed services expose the control plane, integrate IAM, and provision load balancers shows depth, but core Kubernetes concepts remain the priority.
Related
Ready for your next interview?
Download MiPrep AI. Load your resume and the job description. Show up ready.
Free tier · No credit card · macOS 14+ · Windows 10+
Free tier · No credit card · Runs on your Mac or Windows machine