Pods Interview Questions

A liveness probe tells the kubelet whether a container is still running correctly. If the probe fails consecutively beyond the failure threshold, the kubelet kills the container and restarts it according to the Pod's restart policy.

Kubernetes offers three restart policies -- Always, OnFailure, and Never -- that control whether the kubelet restarts containers when they exit. The policy applies to all containers in the Pod and determines behavior after both normal exits and failures.

A readiness probe tells Kubernetes whether a container is ready to accept traffic. If the probe fails, the Pod is removed from Service endpoints but is not restarted. This prevents traffic from being routed to Pods that are still initializing or temporarily unable to serve requests.

Resource requests define the minimum CPU and memory a container needs and are used by the scheduler to place Pods. Limits define the maximum resources a container can use. Exceeding memory limits causes an OOM kill; exceeding CPU limits causes throttling.

A startup probe tells the kubelet whether a container's application has finished starting. While the startup probe is active, liveness and readiness probes are disabled. This prevents slow-starting containers from being killed by aggressive liveness probes before they are initialized.

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network namespace, IP address, and storage volumes, and are always co-scheduled on the same node.

The Downward API exposes Pod and container metadata to running containers as environment variables or volume files. It lets applications access information like the Pod name, namespace, IP address, labels, annotations, and resource limits without querying the Kubernetes API server.

Init containers are specialized containers that run to completion before any app containers start. They execute sequentially and are commonly used for setup tasks like populating shared volumes, waiting for dependencies, or running database migrations.

Kubernetes supports three primary multi-container Pod patterns: sidecar (extends the main container's functionality), ambassador (proxies network connections), and adapter (transforms output). All containers in a Pod share the same network namespace and storage volumes.

A Pod progresses through five phases: Pending (waiting to be scheduled), Running (at least one container is running), Succeeded (all containers exited with code 0), Failed (at least one container exited with a non-zero code), and Unknown (Pod status cannot be determined).

Kubernetes assigns one of three QoS classes to every Pod -- Guaranteed, Burstable, or BestEffort -- based on the resource requests and limits of its containers. The QoS class determines eviction priority when a node runs low on resources: BestEffort Pods are evicted first, then Burstable, then Guaranteed.

The sidecar pattern places a helper container alongside the main application container in the same Pod. The sidecar extends or enhances the app's functionality -- for example, handling logging, proxying, or syncing -- without modifying the application code.

Static Pods are managed directly by the kubelet on a specific node, without the API server's involvement in their creation. They are defined as YAML files in a directory on the node (typically /etc/kubernetes/manifests) and are used to run control plane components like kube-apiserver, etcd, and kube-scheduler.

Ephemeral containers are temporary containers injected into a running Pod for interactive debugging. They are added via kubectl debug and are never restarted. They are essential for troubleshooting distroless or minimal images that lack debugging tools.

A Pod Disruption Budget (PDB) limits the number of Pods of a replicated application that can be voluntarily disrupted at any given time. PDBs ensure that a minimum number of Pods remain available during maintenance operations like node drains, cluster upgrades, or autoscaler scale-downs.

Pod overhead accounts for the resources consumed by the Pod infrastructure itself (sandbox, runtime, pause container) beyond what the application containers request. It is defined in the RuntimeClass and automatically added to the Pod's resource calculations for scheduling, quota accounting, and eviction decisions.

Pod Priority assigns a numerical priority value to Pods via PriorityClasses. Preemption allows the scheduler to evict lower-priority Pods to make room for higher-priority Pods when no node has sufficient resources. This ensures critical workloads can always be scheduled.

A security context defines privilege and access control settings for Pods and their containers. It controls the user/group IDs, Linux capabilities, filesystem permissions, SELinux labels, seccomp profiles, and whether containers run as root or with a read-only filesystem.