Pod
The smallest deployable unit in Kubernetes — one or more containers that share a network namespace, storage volumes and a lifecycle, scheduled together on one node.
The reason a pod exists rather than scheduling containers directly is co-location with shared context. Containers in a pod share an IP address and port space, can communicate over localhost, and can share volumes — which is what makes the sidecar pattern possible.
Consequences that shape design:
Pods are ephemeral and disposable. They get a new IP on every restart, so nothing may depend on a pod's address — that is what Services exist for. Anything that must survive belongs in a persistent volume or an external store.
Scaling is per pod, not per container. If two containers in a pod have different scaling needs, they belong in different pods. Co-location is for genuinely coupled concerns — a proxy, a log shipper, a credential refresher — not for convenience.
The lifecycle is shared. A pod is scheduled, started and terminated as a unit, so a sidecar failing can affect the main container and vice versa. Sidecars that must start before or outlive the main container need explicit ordering support.
Resource requests are summed across containers, which affects scheduling: a pod is placed only where the total fits, so a heavy sidecar reduces packing efficiency across the whole cluster.