Infrastructure & Operations › Kubernetes & Orchestration

Pod

The smallest deployable unit in Kubernetes: one or more containers.

Also known as: kubernetes pod, k8s pod, pod spec

A Pod is the smallest thing Kubernetes schedules. It wraps one or more containers that always run together on the same node. Containers in a pod share a network namespace — the same IP and localhost — and can share storage volumes.

apiVersion: v1
kind: Pod
metadata:
  labels: { app: web }
spec:
  containers:
    - name: web
      image: registry.example.com/web:1.4.2
      ports: [{ containerPort: 8080 }]

In practice you rarely create bare pods. A Deployment or ReplicaSet creates and replaces pods for you; a StatefulSet does so when identity matters. A pod you make by hand isn’t rescheduled if its node dies.

Most pods hold one main container. The common exception is a sidecar: a helper container that shares the pod’s network or filesystem — a log shipper, a proxy, a config reloader. Because they share localhost, a sidecar can sit in front of your app’s traffic.

The classic mistakes:

• Putting unrelated apps in one pod for convenience. They’re now scaled, scheduled and restarted together, and one crash affects the other. Split them into separate pods.
• Expecting a stable identity. Pods are disposable; their name and IP change when they’re replaced. Put a Service in front for a stable address.
• Reaching another pod by IP or localhost. Each pod has its own IP; use the Service name.

Set resource requests and limits on each container, and use ConfigMaps and Secrets for configuration rather than baking it into the image. Pods are the unit that every other workload object ultimately manages.