A Pod is the smallest deployable unit in Kubernetes, encapsulating one or more tightly coupled containers that share a network namespace, inter-process communication, and optionally volumes. In the Kubernetes object model, a Pod represents a single instance of a running process and is described by a manifest containing metadata (such as labels and annotations) and a Pod spec. The required fields in any Pod spec are apiVersion, kind: Pod, metadata.name, spec.containers[].name, and at least one container image. Additional spec fields control runtime behavior, including imagePullPolicy, which determines when the kubelet pulls the image: Always, IfNotPresent, or Never, with :latest-tagged images defaulting to Always and other tags defaulting to IfNotPresent.
Beyond the main application containers, Pods may include Init Containers, which are specialized containers that run to completion before the main containers start. They are typically used for setup tasks such as database migrations or waiting for external dependencies. Native sidecar containers, GA in Kubernetes 1.29 and later, are declared within the initContainers array but use a restartPolicy: Always so they share the Pod's lifecycle and remain running alongside the main containers. The Pod-level spec.restartPolicy field accepts Always, OnFailure, or Never, with normal Pods defaulting to Always, Jobs defaulting to OnFailure, and CronJob-style workloads defaulting to Never.
A Pod's lifecycle is summarized by status phases: Pending, Running, Succeeded, Failed, and Unknown. A common failure indicator is CrashLoopBackOff, which signals that a container is repeatedly crashing; the kubelet waits an increasing backoff period (10s, 20s, 40s, up to 5 minutes) before each restart attempt. Kubernetes also emits time-stamped events for state changes, warnings, and errors, viewable through kubectl describe or kubectl get events, which are essential for diagnosing scheduling and runtime issues.