Pod

On the node, a pod is a sandbox: the runtime first creates a network namespace (traditionally held open by a tiny "pause" container), the CNI plugin assigns it an IP, and the application containers then join that namespace. Containers in a pod therefore share one IP and port space and reach each other on localhost; they share the IPC namespace, and can share a PID namespace if shareProcessNamespace is set. Filesystems are separate unless containers mount the same pod-level volume, such as an emptyDir, which lives as long as the pod. The pod as a whole is scheduled once and never moves: "moving" a pod really means deleting it and creating a new one with a new name and IP, which is why stable addressing goes through Services.

A pod spec can contain three kinds of containers. Init containers run to completion in order before the app containers start. Sidecar containers - declared as init containers with restartPolicy: Always - start before and keep running alongside the main containers, and are terminated after them; this native sidecar support was introduced in Kubernetes 1.28, enabled by default from 1.29 and stable in 1.33. Ephemeral containers can be added to a running pod for debugging with kubectl debug. The kubelet drives health through liveness probes (restart on failure), readiness probes (remove from Service endpoints) and startup probes (hold off the other probes during slow starts). On deletion each container receives SIGTERM, preStop hooks run, and after terminationGracePeriodSeconds (30 seconds by default) remaining processes are killed with SIGKILL.

Resource requests and limits per container determine the pod's QoS class: Guaranteed when every container has equal requests and limits for CPU and memory, BestEffort when none are set, Burstable otherwise; under node memory pressure BestEffort pods are evicted first. Pods are almost never created directly: a Deployment manages ReplicaSets that create pods, while StatefulSets, DaemonSets and Jobs cover stable identity, one-per-node and run-to-completion workloads. Static pods, defined by files on a node, are how kubeadm runs the control plane itself.

Most container-level security in Kubernetes is expressed in the pod's securityContext and spec: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities.drop: [ALL], seccompProfile: RuntimeDefault, and whether hostNetwork, hostPID, hostIPC or hostPath volumes are used. Pod Security Admission checks these fields against the privileged, baseline and restricted profiles per namespace. Because every container in a pod shares the network identity and any mounted service-account token, a compromised sidecar has the same network reach as the main application; a pod is a unit of co-scheduling and shared fate, not a security boundary between its containers.