Kubernetes interview questions

Model answer

A Pod is the smallest deployable unit and represents one or more containers that share the same network namespace and storage. Containers in a Pod can reach each other on localhost and share mounted volumes. You rarely create Pods directly; controllers like Deployments manage them so they are recreated and scaled automatically.

Model answer

A Deployment manages stateless, interchangeable pods with random names and is ideal for web servers and APIs. A StatefulSet gives pods stable, ordered identities and stable per-pod storage, which is required for stateful systems like databases and clustered queues that need predictable names and persistent disks.

Model answer

A Service selects pods using label selectors and tracks their IPs in an Endpoints object that updates as pods come and go. The Service gets a stable virtual IP and DNS name, so clients connect to the Service and kube-proxy load-balances to the current healthy pods, insulating callers from pod churn.

Model answer

The API server is the front door that validates and persists all state to etcd, the cluster key-value store. The scheduler assigns pending pods to nodes based on resources and constraints. The controller-manager runs reconciliation loops that drive actual state toward desired state. On each node, the kubelet runs pods and kube-proxy programs service networking.

Model answer

Both inject configuration into pods as env vars or mounted files, but ConfigMaps hold non-sensitive data while Secrets hold sensitive data. Secrets are base64-encoded, not encrypted, by default, so enable encryption at rest and restrict access with RBAC. Treat Secrets as sensitive even though the encoding is not real protection.

Model answer

Start with kubectl describe pod to read events, then kubectl logs with the previous flag to see output from the crashed container. Common causes are a failing command or bad config, a missing dependency or secret, a failing liveness probe, or an out-of-memory kill. Fix the root cause, then watch the restart succeed.

Model answer

Requests are the resources guaranteed to a container and used by the scheduler to place it; limits are the hard ceiling. If a container exceeds its memory limit it is OOM-killed, and exceeding CPU limit throttles it. Setting them well prevents noisy-neighbor problems and enables reliable autoscaling.

Model answer

RBAC grants permissions through Roles or ClusterRoles that list allowed verbs on resources, bound to subjects via RoleBindings or ClusterRoleBindings. Subjects are users, groups, or service accounts. Pods authenticate with service accounts. The guiding rule is least privilege: grant only the specific verbs and resources each workload needs.

Model answer

The manifest is sent to the API server, authenticated, authorized via RBAC, and validated by admission controllers. The desired state is written to etcd. Controllers notice the change and reconcile: the Deployment controller creates a ReplicaSet, which creates pods, the scheduler binds them to nodes, and kubelets start the containers.

Model answer

A liveness probe tells the kubelet whether a container is still healthy, and a failing one triggers a restart of that container. A readiness probe tells the service whether the pod is ready to receive traffic, and a failing one removes the pod from the endpoints list without restarting it. Use readiness for slow startup or temporary overload, and liveness only for unrecoverable hangs, otherwise you risk restart loops.

Model answer

A Deployment creates a new ReplicaSet and shifts pods over gradually, governed by maxSurge and maxUnavailable so capacity stays steady. Each revision is recorded, so you can inspect history and revert with a single rollback to the previous ReplicaSet. Pair it with readiness probes so traffic only flows to pods that are actually ready, which keeps the update safe.