Pods are Kubernetes’ atomic unit of scheduling - the smallest deployable unit that the cluster manages. While containers are the building blocks, Pods are the fundamental construct that Kubernetes actually schedules and runs.
Core Characteristics
Atomic Scheduling Unit - Kubernetes doesn’t schedule individual containers; it schedules Pods. All containers within a Pod are guaranteed to run on the same node, scheduled together as a single unit.
Shared Network Namespace - Containers within a Pod share the same IP address and port space. They communicate via localhost, as if they were processes running on a single host. This shared networking is managed through Services for external access.
Shared Storage - Pods can define volumes that all containers within the Pod can access. This enables sidecar patterns where one container writes data that another consumes.
Runtime Isolation - While containers in a Pod share networking and storage, they maintain process isolation. Each container runs as a separate Linux process with its own filesystem.
Pod Design Patterns
Pods typically follow one of two patterns:
Single Container Pods - Most common. One application container per Pod, maintaining the granularity benefits of containers.
Multi-Container Pods - Multiple containers working together, such as:
- Sidecar pattern (logging, monitoring agents)
- Ambassador pattern (proxy to external services)
- Adapter pattern (normalizing output formats)
Lifecycle and Identity
Pods are ephemeral by design, embodying the disposable nature of containers. When a Pod dies, Kubernetes creates a new one with a new identity rather than resurrecting the old one.
This ephemerality requires careful handling of runtime dependencies. Persistent data needs PersistentVolumeClaims, and Pod discovery requires Services rather than direct IP references.
Pods implement Managed Lifecycle by responding to platform events. Applications must handle SIGTERM for graceful shutdown, can use PostStart and PreStop hooks for lifecycle control, and may employ Init Containers for staged initialization.
Resource Management
Pods declare their resource requirements through requests and limits. These profiles determine:
- Where the Pod can be scheduled (based on node capacity)
- The Pod’s Quality of Service class
- Whether the Pod might be preempted under resource pressure
Organization
Pods use Labels for organization and selection, enabling flexible grouping across different dimensions. Annotations provide additional non-identifying metadata that tools and controllers can use.
Within a cluster, Namespaces provide logical boundaries for Pod deployment, resource quotas, and access control.