Kubernetes Pods Explained: What a Pod Is, How It Works, and When to Use One

In plain English, what is a pod?

A pod is a thin wrapper that holds one or more containers and gives them a shared environment to run in. When Kubernetes needs to run your application, it does not schedule the container directly. It schedules a pod that contains the container. The pod lands on a node, the node starts the containers inside it, and Kubernetes treats the pod as the unit of work from that point on.

In most cases a pod holds exactly one container: your application. Multi-container pods exist for specific patterns covered below, but single-container pods are the everyday default.

A pod is not the same thing as:

• A container. A container is the application process. A pod is the Kubernetes envelope around it.
• A node. A node is the VM that runs pods. One node can run many pods.
• A Deployment. A Deployment is a controller that creates and manages pods. The pod is what actually runs; the Deployment is what keeps it healthy.

What a Kubernetes pod is

A pod is defined by a few core properties that set it apart from a standalone container:

• Smallest deployable unit. You cannot schedule a bare container in Kubernetes. The pod is the minimum schedulable object.

• Wraps one or more containers. All containers in a pod are defined in one spec and managed as one unit.

• Shared network namespace. All containers in a pod share the same IP address and port space. They communicate with each other over localhost. Each pod gets its own cluster-internal IP.

• Shared storage. Containers in a pod can mount the same volumes, letting them read and write shared files.

• Co-scheduled on the same node. All containers in a pod always land on the same node. They start and stop together.

• Ephemeral by design. Pods are not meant to be long-lived. They can be deleted, rescheduled, or replaced at any time. Persistent state belongs in a volume or external storage, not inside the pod.

How Kubernetes pods work

When you submit a pod spec to Kubernetes, this sequence happens:

1. The API server accepts the pod spec and stores it in etcd. The pod is in the Pending phase.

2. The scheduler watches for unscheduled pods. It evaluates node capacity, resource requests, affinity rules, and taints, then assigns the pod to a suitable node.

3. The kubelet on that node picks up the assignment. It pulls the container images, starts the containers, and begins running health checks.

4. Containers in the same pod share a network namespace. They all live at the same IP address and can call each other over localhost.

5. If a container crashes, the kubelet restarts it based on the pod’s restartPolicy (default: Always). If the container keeps crashing, the pod enters CrashLoopBackOff.

# simple-pod.yaml — a standalone pod (useful for learning and debugging)
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  containers:
    - name: app
      image: us-central1-docker.pkg.dev/my-project/my-repo/my-app:v1
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
      env:
        - name: APP_ENV
          value: "production"

# Apply the manifest
kubectl apply -f simple-pod.yaml

# List pods in the default namespace
kubectl get pods

# Get full details: events, conditions, container statuses
kubectl describe pod my-app

# View container logs
kubectl logs my-app

# View logs from the previous (crashed) container instance
kubectl logs my-app --previous

# Open a shell inside the running container
kubectl exec -it my-app -- bash

# Delete the pod
kubectl delete pod my-app

Pod lifecycle

Every pod moves through a defined set of phases from creation to termination:

CrashLoopBackOff

CrashLoopBackOff is not a phase. It is a container restart status that appears when Kubernetes keeps restarting a container because it keeps crashing. Restart delays increase exponentially: 10s, 20s, 40s, up to 5 minutes per cycle.

Common causes of CrashLoopBackOff:

• The app exits with an error immediately on startup (missing config, bad arguments)
• A required environment variable, config file, or Secret is missing. See Managing Secrets in Kubernetes
• The container is killed by OOM because memory limits are too low
• The entrypoint or command in the image is incorrect

What to check first

# Step 1: Logs from the PREVIOUS container instance
kubectl logs my-app --previous

# Step 2: Events and container state
kubectl describe pod my-app

# Step 3: Current pod status and node placement
kubectl get pod my-app -o wide

# Watch pod status changes in real time
kubectl get pods --watch

Container restart behaviour is controlled by spec.restartPolicy:

• Always (default) — restart on any termination. Use for long-running services.
• OnFailure — restart only on non-zero exit codes. Use for batch jobs.
• Never — do not restart. Use for one-shot tasks where you want to inspect the result.

Pod networking

Every pod gets its own IP address from the cluster’s pod CIDR range. On GKE VPC-native clusters (the default since GKE 1.21), pod IPs are real VPC IP addresses, reachable from other VMs in the same VPC without NAT or tunnelling. See GKE Networking Model for how alias IP ranges make this work.

• Containers in the same pod communicate via localhost, with no network hop.

• Pods across the cluster communicate using pod IPs with no NAT required within the cluster.

• Pod IPs are ephemeral. They change when a pod is rescheduled, restarted, or replaced. Never hardcode a pod IP.

• DNS within the cluster follows the pattern service-name.namespace.svc.cluster.local.

# Get a pod's IP address
kubectl get pod my-app -o jsonpath='{.status.podIP}'

# Port-forward to your local machine for debugging
kubectl port-forward pod/my-app 8080:8080

# Then in another terminal:
curl http://localhost:8080

Multi-container pods

Most pods run a single container. Multi-container pods are used for two specific patterns where containers need to be tightly coupled on the same node with shared network and storage access.

Sidecar pattern

A sidecar container runs alongside the main container and handles supporting concerns: log shipping, metrics collection, or a service mesh proxy like Envoy. Because the sidecar shares the same network namespace and volumes, it can tail log files or intercept traffic without any changes to the main application code.

spec:
  containers:
    - name: app
      image: my-app:v1
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
    - name: log-shipper
      image: fluent/fluentd:v1.16
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
          readOnly: true
  volumes:
    - name: logs
      emptyDir: {}

Init containers

Init containers run to completion before the main application container starts. Use them for setup tasks: waiting for a database to become ready, fetching configuration from a remote source, or seeding a shared volume.

spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.36
      command: ['sh', '-c',
        'until nc -z postgres-service 5432; do echo waiting for db; sleep 2; done']
  containers:
    - name: app
      image: my-app:v1

When to use pods

Every workload in Kubernetes uses pods. The question is not whether to use pods, but which controller should create them for you.

You create a pod directly only when learning, testing, or debugging a specific node. In all other cases, you define a pod template inside one of the controllers above, and the controller handles creating, replacing, and scaling pods for you.

Pod vs container vs Deployment

These three concepts are closely related but operate at different levels:

The mental model: a container is what runs, a pod is how Kubernetes runs it on a node, and a Deployment is how Kubernetes keeps the right number of pods running over time.

A pod created without a controller is called a naked pod. If the node it runs on fails, the pod is gone with no replacement. A pod managed by a Deployment that disappears is automatically replaced. This is why you should almost never create naked pods in production.