›What's the difference between a Pod and a Deployment?
A Pod is the smallest deployable unit — one or more containers sharing network and storage. A Deployment manages a ReplicaSet of Pods declaratively: desired replica count, rolling update strategy, and rollback history. You rarely create bare Pods directly in production; Deployments (or StatefulSets, DaemonSets) manage them for you.
›What's the difference between a Service and an Ingress?
A Service gives a stable virtual IP and DNS name to a set of Pods selected by label, load-balancing traffic between them — it operates at L4. An Ingress is an L7 HTTP(S) router in front of Services, handling host/path-based routing and TLS termination for many Services through one entry point.
›How does a readiness probe differ from a liveness probe?
A readiness probe controls whether a Pod receives traffic from a Service, without restarting it on failure — for "temporarily not ready." A liveness probe controls whether the container gets killed and restarted — for "this process is stuck." Conflating them either restart-loops a warming-up pod or leaves a truly wedged one serving traffic.
›What causes CrashLoopBackOff, and how do you debug it?
The container starts and exits repeatedly, with Kubernetes backing off between restarts. Start with
kubectl logs POD_NAME --previous (the current container has no logs yet right after a restart) and
kubectl describe pod for the exit code — 137 usually means OOMKilled, other non-zero codes point at an
application or startup config error.
›What's the difference between a StatefulSet and a Deployment?
A Deployment's Pods are interchangeable — any replica can be replaced by any other. A StatefulSet gives each replica a stable, unique identity (ordinal name, stable network identity, and its own PersistentVolumeClaim that survives rescheduling) — needed for anything where replica identity or storage matters, like a database cluster.
›How does Kubernetes decide where to schedule a Pod?
The scheduler filters nodes by hard requirements (resource requests fit, taints are tolerated, nodeSelector/affinity rules match), then scores the remaining candidates (spreading, resource balance) to pick the best fit. Requests are what scheduling decisions are based on; limits are enforced only at runtime by the kubelet.
›What's the difference between a resource request and a resource limit?
A request is what the scheduler reserves for the container and guarantees is available on its node — it drives scheduling. A limit is the hard ceiling the kubelet enforces at runtime: exceeding a memory limit gets the container OOMKilled; exceeding a CPU limit gets it throttled, not killed.
›What is a namespace, and what does it isolate?
A namespace is a logical partition of a cluster's resources — most object names only need to be unique within a namespace, and RBAC, resource quotas and network policies can all be scoped to one. It does not isolate nodes or provide strong security boundaries on its own; Pods in different namespaces can still reach each other over the network unless a NetworkPolicy says otherwise.
›How would you debug a Service that isn't routing traffic to any Pods?
Start with kubectl get endpoints SERVICE_NAME — empty endpoints means the Service's label selector isn't matching
any Pod that's currently Ready. Check the selector against the Pod's actual labels, confirm the Pod is passing its
readiness probe, and confirm targetPort matches the port the container is actually listening on.
›What is a DaemonSet used for?
Ensures exactly one copy of a Pod runs on every (or a selected subset of) node — the standard pattern for node-level agents: log collectors, metrics exporters, CNI plugins. Unlike a Deployment, replica count isn't set directly; it's derived from the number of matching nodes.