If you are new to Kubernetes, stop thinking about “Running Containers.” In Kubernetes, we don’t run containers directly. We run Pods.

Think of a Pod as a “wrapper” or a “logical host.” It is the smallest thing you can create and manage in Kubernetes. Just like a pea pod 🫛 can hold one or more peas, a Kubernetes Pod can hold one or more containers. These containers live together, share resources, and help each other out. They are born together, they work together, and they die together.

A Pod is not just a container; it is a logical host. Think of a Pod like a Virtual Machine (VM) and the containers inside it as processes running on that VM.

1. Shared Network: All containers in a Pod share the same Network Namespace. They have the same IP address and can talk to each other via localhost.
2. Shared Storage: Containers can access the same shared volumes, allowing data exchange (e.g., a log shipper reading logs written by an app).
3. Shared Lifecycle: They are scheduled together, start together, and die together.

The Pod

The Pod is the smallest deployable computing unit, but it is much more than a wrapper for a single container. It acts as a logical host, creating an encapsulated environment that mimics a Virtual Machine (VM). While containers provide isolation from the outside world, the Pod provides a shared context for the containers inside it.

To truly understand a Pod, you must view it through the lens of the “VM Analogy”:

• The Pod is the VM. It owns the IP address, the network ports, and the storage volumes.
• The Containers are the Processes. Just as multiple processes (e.g., an app server and a log agent) run on the same server and share resources, multiple containers run inside a Pod and share the Pod’s environment.

This architecture is achieved through three fundamental pillars of sharing: Networking, Storage, and Lifecycle.

• “One Pod = One IP Address.” No matter how many containers are inside, they all share that single IP.
• “Pods are Mortal.” They are born, they do their job, and they die. They are not resurrected; they are replaced.
• “Localhost Communication.” Containers in the same Pod talk to each other using localhost, just like processes on your laptop.
• “Atomic Unit.” You never deploy a “container” directly in Kubernetes; you always deploy a Pod.
• Ephemeral: Pods are temporary. If a node dies, the Pod dies.
• Co-located: Containers in a Pod are always scheduled on the same Node.
• Shared Context: They share Network, Storage, and Lifecycle.

Containers with the Pod.

–

Shared Network: The “IP-per-Pod” Model

In a traditional VM or physical server, every process running on the host shares the same network interface. Kubernetes applies this exact model to Pods.

• The Network Namespace: When a Pod starts, Kubernetes first launches a tiny, hidden container often called the “pause container” (or infrastructure container). Its sole job is to hold the Network Namespace open. All subsequent user containers (your app, your sidecars) join this exact same namespace.
  • Each pod gets a unique IP address within the cluster.
• Single Identity: Because they share the network namespace, every container in the Pod shares the same IP address and MAC address. To the rest of the cluster, the Pod is a single addressable endpoint.
• Localhost Communication: Containers within the Pod can communicate with each other using localhost.
  • Example: If you have a web server container listening on port 80 and a database proxy container in the same Pod, the web server can connect to localhost:5432 to reach the proxy.
• Port Coordination: Just like processes on a VM. The containers in a Pod cannot bind to the same port. You cannot run two containers that both listen on port 80 inside the same Pod; you will get a “Port already in use” error.

Shared Storage: Data Gravity and Volumes

Containers are ephemeral; when they crash, their filesystem is lost. Pods solve this by providing Volumes storage abstractions that are bound to the lifecycle of the Pod, not the individual container.

• Volume Mounting: A Volume is defined at the Pod level (like mounting an external hard drive to a VM). Individual containers can then “mount” this volume into their own internal file systems.
• Data Exchange patterns: This capability is the backbone of multi-container design patterns.
  • The Sidecar Pattern: A primary container writes logs to a shared volume (e.g., /var/log/app). A secondary “sidecar” container (like Fluentd or Logstash) mounts that same directory, reads the logs, and pushes them to a central logging system.
  • The Init Container Pattern: An init container spins up, downloads a configuration file or a dataset to a shared volume, and then terminates. The main application container starts up, mounts that volume, and uses the data.

Shared Lifecycle: Atomic Scheduling

The Pod is the atomic unit of scheduling in Kubernetes. The scheduler does not notice individual containers; it only sees Pods.

• Co-Scheduling: A Pod is either scheduled to a node or it isn’t. You will never have a situation where “Container A” of a Pod is running on Node 1 while “Container B” of the same Pod is running on Node 2. They are physically colocated on the same hardware.
• Symbiotic Existence:
  • Startup: Containers in a Pod start in a defined order (Init containers first, then app containers).
  • Termination: When a Pod is deleted, all containers receive termination signals (SIGTERM) simultaneously.
• Restart vs. Recreate: If a container crashes (process fails), the kubelet on the node will restart that specific container (keeping the Pod and its IP address alive). However, if the Pod itself is evicted or deleted, the IP is lost, and a brand new Pod must be created elsewhere.

Kubernetes Pods – Official Docs

Pod Manifest: The YAML file

Create pod using this yaml file.

# 1. API VERSION
# Specifies the version of the Kubernetes API to use.
# 'v1' is the core version usually used for Pods, Services, and Namespaces.
apiVersion: v1

# 2. KIND
# The type of Kubernetes resource you want to create.
kind: Pod

# 3. METADATA
# Data that helps uniquely identify the object, including a name and optional namespace.
metadata:
  # The name of the Pod. Must be unique within its namespace.
  name: example-web-pod

Kubernetes Pod Lab –