Pod: KCSA practice questions

A Pod is the smallest deployable unit in Kubernetes: a group of one or more containers with shared storage and network resources and a specification for how to run them. The containers in a Pod are co-located and co-scheduled, and their shared context is a set of Linux namespaces and cgroups. Within one Pod, containers share an IP address and port space and can reach each other over localhost, which is why tightly coupled helpers such as a log shipper live in the same Pod as the application rather than in a separate one. A Pod can also hold init containers, which must run to completion before the app containers start.

Pods are designed to be relatively ephemeral and disposable, so you rarely create them directly. Workload resources create and replace them for you. A Deployment manages interchangeable replicas. A StatefulSet runs related Pods that track state, for example by matching each Pod with its own PersistentVolume. A DaemonSet places a Pod on every node that matches its specification, including nodes added later, which suits node-local facilities such as monitoring or log agents. A Job runs a task to completion once, and a CronJob runs the same Job repeatedly on a schedule.

Static Pods are an exception to the usual control-plane management. They are managed directly by the kubelet on one specific node, from manifest files in a directory such as /etc/kubernetes/manifests, and their main use is running a self-hosted control plane. The kubelet creates a read-only mirror Pod in the API server so the static Pod is visible, but deleting that mirror Pod with kubectl does not stop the static Pod; the kubelet simply recreates the mirror.

Termination is graceful by default. When a Pod is deleted, it gets a grace period (terminationGracePeriodSeconds, default 30 seconds) during which the main process receives its stop signal; containers still running when the period expires are killed. kubectl delete accepts --grace-period to override that value, and a force deletion needs --force together with --grace-period=0. A forced delete removes the Pod object from the API server without waiting for the kubelet to confirm the containers have stopped, so the workload may keep running on the node.

Two namespace-level controls shape Pod resources and availability. A LimitRange constrains the requests and limits that each Pod or container in a namespace may specify, enforcing minimums, maximums and defaults. A PodDisruptionBudget limits how many Pods of a replicated application can be down at the same time because of voluntary disruptions such as a node drain; it cannot prevent involuntary failures, and deleting Pods or Deployments directly bypasses it.