DevOps Dictionary

Kubernetes Pod is the smallest deployable unit in Kubernetes. A pod runs one or more containers that share the same network namespace, storage volumes, and lifecycle, which means the containers inside a pod are scheduled, started, stopped, and moved together.

What a Kubernetes Pod does

A pod gives Kubernetes a standard way to run application workloads. Instead of scheduling individual containers directly, Kubernetes schedules pods onto worker nodes.

In practical terms, a pod can run:

• A single application container, such as a Node.js API, Go service, or Python worker.
• An application container plus a helper container, such as a log shipper, proxy, or sidecar.
• Short-lived workloads, such as database migrations, batch jobs, or CI-related tasks.

How a pod works

When you create a pod, Kubernetes assigns it to a node with enough available CPU, memory, and other requested resources. The kubelet on that node then asks the container runtime, such as containerd, to start the pod’s containers.

All containers in the same pod share:

• Network identity: Containers share the same pod IP address and can communicate with each other over localhost.
• Storage volumes: Containers can mount the same Kubernetes volumes to share files.
• Lifecycle: Kubernetes treats the pod as one scheduling unit. If the pod moves to another node, all its containers move together.

Pods are usually temporary. If a pod crashes, gets evicted, or is replaced during a rollout, Kubernetes creates a new pod rather than repairing the old one in place.

Common use cases

• Running a web service: A Deployment creates and manages multiple identical pods behind a Service.
• Running a background worker: A worker pod consumes messages from a queue such as RabbitMQ, Kafka, or Amazon SQS.
• Running a sidecar pattern: A pod runs an app container alongside a helper container for logging, service mesh proxying, or configuration reloads.
• Running batch work: A Job creates pods that run until completion, such as a report generator or migration script.
• Running data tools: Systems such as Apache Airflow often run components as pods on Kubernetes, including schedulers, workers, and web servers. For a practical example, see this guide to deploying Apache Airflow on AWS EKS.

Key parts of a pod

• Containers: The actual application processes running from container images.
• Pod spec: The Kubernetes configuration that defines containers, images, ports, volumes, environment variables, probes, and resource requests.
• Labels: Key-value metadata used by Services, Deployments, NetworkPolicies, and other Kubernetes objects to select pods.
• Volumes: Shared storage mounted into one or more containers in the pod.
• Resource requests and limits: CPU and memory settings that affect scheduling and runtime behavior.
• Probes: Health checks such as readiness, liveness, and startup probes.
• Service account: The Kubernetes identity the pod uses when it needs to access the Kubernetes API.

Pod lifecycle

A pod moves through several phases during its life:

• Pending: Kubernetes accepted the pod, but it has not started all containers yet. This can happen while waiting for scheduling, image pulls, or volume attachment.
• Running: The pod is assigned to a node and at least one container is running.
• Succeeded: All containers completed successfully and will not restart.
• Failed: At least one container exited with failure and will not restart.
• Unknown: Kubernetes cannot determine the pod state, often because the node is unreachable.

For long-running applications, you usually do not create bare pods manually. You use controllers such as Deployments, StatefulSets, DaemonSets, or Jobs. These controllers create and replace pods as needed.

Pod vs container

A container is a single isolated process environment created from an image. A pod is the Kubernetes wrapper around one or more containers.

Most pods run one main container. Multi-container pods are useful when the containers must be tightly coupled. For example, a pod might run a web app container and a sidecar container that exports metrics or handles local proxy traffic.

Pod vs Deployment

A pod runs the workload, while a Deployment manages replicas and rollouts for stateless applications.

If you create one pod directly and it gets deleted, Kubernetes does not automatically recreate it. If you create a Deployment with three replicas, Kubernetes keeps three matching pods running and replaces failed pods automatically.

Pod vs Service

A pod has its own IP address, but that IP is temporary. When the pod is replaced, the new pod gets a different IP.

A Service gives a stable network endpoint for a group of pods. For example, a backend Service can route traffic to all pods labeled app=backend, even as pods are created and destroyed during deployments.

Simple example

This pod runs one Nginx container and exposes port 80 inside the pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

This is useful for learning, testing, or debugging. In production, you would usually wrap this workload in a Deployment and expose it with a Service.

Benefits

• Clear scheduling unit: Kubernetes can place, restart, and replace workloads consistently.
• Shared local context: Containers in the same pod can communicate over localhost and share mounted volumes.
• Good fit for automation: Pods work with Deployments, Jobs, autoscalers, health checks, and rollout strategies.
• Declarative configuration: You can define pods and related resources in YAML, Helm charts, Kustomize, Terraform, or GitOps workflows. For example, teams often manage Kubernetes manifests through infrastructure-as-code workflows such as deploying Kubernetes resources using Terraform.

Tradeoffs and limitations

• Pods are ephemeral: Do not depend on a pod IP, local filesystem, or pod name staying the same.
• Bare pods are rarely enough: Use Deployments, StatefulSets, DaemonSets, or Jobs for reliable production behavior.
• Resource settings matter: Missing CPU and memory requests can cause poor scheduling decisions. Missing limits can allow a container to consume too much memory or CPU.
• Multi-container pods can get complex: Use them when containers need tight coupling. Avoid grouping unrelated services in one pod.
• Upgrades can affect pods: Node drains, Kubernetes version changes, and runtime updates can restart or reschedule pods. If you operate clusters in production, plan for this during Kubernetes upgrades.

How pods fit into cloud infrastructure

Pods often depend on cloud resources such as load balancers, databases, queues, object storage, IAM roles, and DNS records. Platform teams usually manage those dependencies separately from the pod itself.

For example, an application pod on Amazon EKS might connect to an RDS database, read files from S3, and receive traffic through an AWS load balancer. Some teams define both Kubernetes and cloud resources declaratively. Tools such as Crossplane can manage cloud resources through Kubernetes APIs, as shown in this guide to deploying AWS resources using Crossplane on Kubernetes.

Operational best practices

• Use controllers, not standalone pods: Use Deployments for stateless services, StatefulSets for stable identity and storage, Jobs for run-to-completion work, and DaemonSets for node-level agents.
• Set resource requests and limits: Start with realistic values, such as 250m CPU and 256Mi memory for a small API, then tune based on metrics.
• Add readiness probes: Prevent traffic from reaching a pod before the app is ready.
• Add liveness probes carefully: A bad liveness probe can cause restart loops. Use it when the app can get stuck and needs a restart.
• Keep one main responsibility per pod: Use sidecars for tightly related helper functions, not as a way to pack multiple services together.
• Send logs to stdout and stderr: This keeps logs compatible with common Kubernetes logging pipelines.
• Avoid storing important data in the container filesystem: Use PersistentVolumes, object storage, or an external database when data must survive pod replacement.

Real-world example

Suppose you run a SaaS API on Kubernetes. You might define a Deployment with five replicas. Kubernetes creates five pods, each running the same API container. A Service sends traffic to all ready pods. If one pod crashes, the Deployment creates a replacement. If you release version 1.8.0, Kubernetes gradually creates new pods with the new image and removes old pods after the new ones pass readiness checks.

The key point: your users connect to a stable Service, while Kubernetes continuously creates, replaces, and moves pods behind the scenes.