What Are Pods in Kubernetes?

What are Pods in Kubernetes?

A Pod is the smallest deployable unit in Kubernetes cluster.

A Pod represents one or more containers that are:

• Scheduled together
• Run on the same node
• Share the same network and storage resources

In practice, a Pod is the unit that Kubernetes creates, starts, stop, and replaces, not the container itself.

Key characteristics of a Pod

• One IP address per Pod
• Shared localhost network namespace
• Shared volumes
• Containers are tightly coupled
• Pods are ephemeral (short-lived by design)

If a Pod dies, Kubernetes does not resurrect it. Instead, it create a new Pod to replace it.

Origin of the Word “Pod”

The word Pod comes form nature.

A pod of whales is a group of whales that travel together.

In Kubernetes terms:

• Container = Whale
• Pod = Group of whales that live and move together

This analogy works well, since containers inside a Pod:

• Start together
• Stop together
• Share resources
• Are tightly coupled

Pods vs Containers

A common beginner misconception is:

“A Pod is a container.”

This is not correct

• A container is a runtime abstraction (Docker, containerd, etc…)
• A Pod is a Kubernetes abstraction that wraps containers

That said, the most common Pod type is a single-container Pod, which explains the confusion.

Single-Container Pods

A single-container Pod contains exactly one container.

This is:

• The most common Pod type
• The recommended default unless you have a strong reason otherwise

Characteristics

• One main process
• One clear responsibility
• Pod lifecycle closely matches the container lifecycle

Typical use cases

• Stateless services
• REST APIs
• Background workers
• Cron Jobs

Example:

Pod
 └─ nginx container

REST API service example:

Pod
 └─ Node.js / Java / Go API

Best practice

Prefer single-container Pods unless you need tight coupling or shared resources between containers.

Multi container

A multi-container Pod contains multiple containers that are designed to work together.

These containers:

• Share the same IP address
• Share ports
• Share mounted volumes
• Communicate via localhost
• Start and stop together

Shared resources

• Network namespace (one IP per Pod)
• Storage volumes
• Pod lifecycle

Pod
 ├─ app container
 └─ log-collector sidecar

Common Multi-Container Patterns

Sidecar Pattern

A helper container that extends or enhances the main container.

Common uses:

• Logging
• Metrics
• Proxies
• Security agents

Example:

Pod
 ├─ Java app
 └─ Fluent Bit sidecar

Ambassador Pattern

A proxy container that handles communication with external services.

Adapter Pattern

A container that transforms output into a common format, such as logs or metrics.

When to use Multi-Container Pods

Multi-container Pods make sense when:

• One container supports another
• Containers are meaningless on their own
• You need shared filesystem access
• You rely on localhost-based communication

Avoid them when:

• Container can run independently
• You are grouping services only for convenience

Init container

An Init Container is a special type of container that runs before the main application containers start.

How Init Containers Work

• Run sequentially
• Must complete successfully
• Exit after completion
• Block Pod startup if they fail

Pod startup flow: InitContainer 1 → InitContainer 2 → App containers

Init containers:

• Share volumes with app containers
• Are not long-running.

Common Init Container Use Cases

• Database migrations
• Waiting for dependencies
• Pre-loading configuration or data
• Setting file permissions

Database migration example:

InitContainer: run flyway/liquibase
App container: start API

Executing Commands Inside a Pod

To open a shell inside a running container in a Pod:

kubectl exec -it pod/httpd -- /bin/bash**

This command:

• Opens an interactive shell
• Runs inside the container
• Is useful for debugging and inspection

Multi-Container Pod Example

If a Pod has multiple container, specify the container name:

kubectl exec -it pod/my-pod -c app-container -- /bin/bash

Notes

• The container image must include /bin/bash (otherwise use /bin/sh)
• Any changed made inside the container are temporary and lost when the Pod is recreated

Summary

• A Pod is the smallest unit Kubernetes manages
• Pods contain one or more containers
• Most Pods should be single-container Pods
• Multi-container Pods are for tightly coupled workloads
• Init containers prepare the environment before app startup
• Pods are ephemeral and disposable by design
• Understanding Pods is the foundation to understanding Kubernetes as a whole