Kubernetes Interview Questions

Q: What is the difference between a Pod and a Deployment?

A Pod is the smallest unit — one or more containers with shared networking/storage. Running Pods directly is not recommended — if it crashes, it stays dead. A Deployment wraps Pods in a ReplicaSet that maintains a desired number of replicas, provides rolling updates, rollback capability, and auto-restarts failed Pods.

Q: What is the difference between liveness and readiness probes?

Liveness probe checks if the container is alive — if it fails, Kubernetes restarts the container. Readiness probe checks if the container is ready to serve traffic — if it fails, the Pod is removed from Service endpoints (no requests routed to it) but not restarted. Use readiness for warm-up; use liveness for deadlock detection.

Q: What is the difference between ClusterIP, NodePort, and LoadBalancer?

• ClusterIP — internal DNS name, reachable only within the cluster

• NodePort — exposes on every node at a static port (30000-32767), useful for testing

• LoadBalancer — provisions a cloud load balancer (GKE, EKS, AKS); for production external traffic

Q: What is a namespace and why use it?

Namespaces provide virtual isolation within a cluster. Common uses: separate environments (dev/staging/prod in one cluster), team isolation, resource quota enforcement. Resources with the same name can coexist in different namespaces. ClusterIP services are DNS-resolvable across namespaces as service.namespace.svc.cluster.local.

Q: What is a rolling update and how does it work?

A rolling update gradually replaces old Pods with new ones. With maxSurge=1 and maxUnavailable=0: one new Pod is created (total N+1), waits for it to be ready, then terminates one old Pod — repeating until all are replaced. Zero-downtime deployment. kubectl rollout undo reverses it.

Q: What are resource requests and limits?

Requests are what the scheduler uses to find a node with enough capacity — the Pod is guaranteed this amount. Limits are the maximum a container can use before being throttled (CPU) or OOM-killed (memory). Always set both: requests too high wastes resources, too low causes scheduling failures; limits prevent noisy-neighbor problems.