DEV Community

Cover image for Kubernetes Series - Part 2: Container vs Pod vs Deployment Explained
Shiva Krishna beepeta
Shiva Krishna beepeta

Posted on

Kubernetes Series - Part 2: Container vs Pod vs Deployment Explained

#devops #containers #docker #kubernetes

Kubernetes Series - Part 2: Container vs Pod vs Deployment Explained

In the previous article, we explored Kubernetes Architecture and how different components interact inside a cluster.

In this article, we'll dive into one of the most fundamental Kubernetes concepts:

Container → Pod → Deployment

Understanding these three concepts is critical because almost every Kubernetes workload is built on top of them.

Why Do We Need Container, Pod and Deployment?

A common misconception among beginners is:

"Aren't Container, Pod, and Deployment all used to run applications?"

The answer is Yes, but each solves a different problem.

Resource Responsibility
Container Runs the application
Pod Hosts and groups containers
Deployment Manages and maintains Pods

Think of it like:

Application
    ↓
Container
    ↓
Pod
    ↓
Deployment
Enter fullscreen mode Exit fullscreen mode

Each layer adds new capabilities.

Step 1: Understanding Containers

A Container is the actual instance of your application.

For example:

docker run nginx
Enter fullscreen mode Exit fullscreen mode

This launches an Nginx container.

A container includes:

  • Application code
  • Runtime environment
  • Libraries
  • Dependencies
  • Configuration

Real-World Example

Imagine you have a Java application.

Java Application
       │
       ▼
Docker Image
       │
       ▼
Container
Enter fullscreen mode Exit fullscreen mode

The container contains:

JDK
+
Application JAR
+
Required Libraries
Enter fullscreen mode Exit fullscreen mode

Everything needed to run the application travels together.

This is why containers work consistently across:

  • Local Laptop
  • QA Environment
  • Staging
  • Production

Problem With Using Only Containers

Suppose your container crashes.

Container
    ↓
Crash
    ↓
Application Down
Enter fullscreen mode Exit fullscreen mode

Questions arise:

  • Who recreates the container?
  • Who scales containers?
  • Who updates them?

A standalone container cannot solve these problems.

This is where Kubernetes enters the picture.

Step 2: Understanding Pods

Kubernetes doesn't directly manage containers.

Instead, Kubernetes runs containers inside Pods.

What Is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

A Pod can contain:

1 Container
Enter fullscreen mode Exit fullscreen mode

or

Multiple Containers
Enter fullscreen mode Exit fullscreen mode

Single Container Pod

Most common scenario:

Pod
 │
 └── Nginx Container
Enter fullscreen mode Exit fullscreen mode

Multi-Container Pod 

Pod
 │
 ├── Application Container
 │
 └── Log Forwarder Container
Enter fullscreen mode Exit fullscreen mode

Example:

Application Container
       +
Fluent Bit Container
Enter fullscreen mode Exit fullscreen mode

The Fluent Bit sidecar collects logs generated by the application.

Why Do Containers Need Pods?

Pods provide three important capabilities.

1. Shared Network

Every Pod gets a unique IP.

Example:

Pod IP = 10.244.1.5
Enter fullscreen mode Exit fullscreen mode

All containers inside that Pod share the same IP.

Application Container
Logging Container
Enter fullscreen mode Exit fullscreen mode

can communicate using:

localhost
Enter fullscreen mode Exit fullscreen mode

2. Shared Storage

Containers inside the same Pod can access common storage.

volumeMounts:
Enter fullscreen mode Exit fullscreen mode

Example:

Application writes logs
        ↓
Shared Volume
        ↓
Log Collector reads logs
Enter fullscreen mode Exit fullscreen mode

3. Shared Lifecycle

Containers inside a Pod:

  • Start together
  • Stop together
  • Get scheduled together

Kubernetes treats them as a single unit.

Life of a Pod

Let's say Kubernetes creates a Pod.

Pod Created
      ↓
Container Starts
      ↓
Application Running
Enter fullscreen mode Exit fullscreen mode

Everything works fine.

Suddenly:

Node Failure
Enter fullscreen mode Exit fullscreen mode

or

Application Crash
Enter fullscreen mode Exit fullscreen mode

Result:

Pod Lost
Enter fullscreen mode Exit fullscreen mode

Now what?

Problem With Pods

Pods are temporary.

They are designed to be:

Created

Destroyed

Recreated

A standalone Pod does not automatically recreate itself.

Example:

kubectl delete pod nginx
Enter fullscreen mode Exit fullscreen mode

Result:

Pod Deleted
Enter fullscreen mode Exit fullscreen mode

No automatic recovery.

Application becomes unavailable.

Step 3: Understanding Deployments

This is where Deployments become important.

What Is a Deployment?

A Deployment is a Kubernetes controller that manages Pods.

Instead of creating Pods directly:

kind: Pod
Enter fullscreen mode Exit fullscreen mode

we create:

kind: Deployment
Enter fullscreen mode Exit fullscreen mode

Deployment Architecture 

Deployment
     │
     ▼
ReplicaSet
     │
     ▼
Pods
     │
     ▼
Containers
Enter fullscreen mode Exit fullscreen mode

Why Do We Need Deployments?

Deployments solve four major problems:

Self-Healing

Scaling

Rolling Updates

Rollbacks

1. Self-Healing

Deployment maintains a desired state.

Example:

replicas: 3
Enter fullscreen mode Exit fullscreen mode

Desired state:

3 Pods Running
Enter fullscreen mode Exit fullscreen mode

Current state:

Pod-1
Pod-2
Pod-3
Enter fullscreen mode Exit fullscreen mode

Pod-2 crashes.

Pod-2 Down
Enter fullscreen mode Exit fullscreen mode

Deployment detects:

Desired = 3
Actual  = 2
Enter fullscreen mode Exit fullscreen mode

Immediately creates:

New Pod-2
Enter fullscreen mode Exit fullscreen mode

Final state:

Pod-1
Pod-2
Pod-3
Enter fullscreen mode Exit fullscreen mode

This feature is called Self-Healing.

2. Scaling

Traffic increases.

100 Users
    ↓
10,000 Users
Enter fullscreen mode Exit fullscreen mode

You need more application instances.

Update:

replicas: 10
Enter fullscreen mode Exit fullscreen mode

or run:

kubectl scale deployment nginx --replicas=10
Enter fullscreen mode Exit fullscreen mode

Deployment creates additional Pods automatically.

Pod-1
Pod-2
...
Pod-10
Enter fullscreen mode Exit fullscreen mode

3. Rolling Updates

Current Application:

v1.0
Enter fullscreen mode Exit fullscreen mode

New Release:

v2.0
Enter fullscreen mode Exit fullscreen mode

Without Deployment:

Stop Everything
Deploy New Version
Start Everything
Enter fullscreen mode Exit fullscreen mode

Downtime occurs.

With Deployment:

Create New Pod
      ↓
Verify Health
      ↓
Remove Old Pod
Enter fullscreen mode Exit fullscreen mode

Repeat until every Pod is updated.

No Downtime
Enter fullscreen mode Exit fullscreen mode

4. Rollback

New release causes issues.

v2.0
  ↓
Application Failure
Enter fullscreen mode Exit fullscreen mode

Deployment allows rollback.

kubectl rollout undo deployment/nginx
Enter fullscreen mode Exit fullscreen mode

Kubernetes restores the previous working version.

v1.0 Restored
Enter fullscreen mode Exit fullscreen mode

The Complete Picture 

Deployment
│
├── Maintains Desired State
├── Performs Scaling
├── Handles Updates
├── Provides Rollback
└── Creates Pods
        │
        ▼
       Pod
        │
        ├── Shared Network
        ├── Shared Storage
        └── Shared Lifecycle
                │
                ▼
           Container
                │
                └── Runs Application
Enter fullscreen mode Exit fullscreen mode

Real Production Example

Consider an e-commerce application.

Container 

Spring Boot Application
Enter fullscreen mode Exit fullscreen mode

runs inside:

Container
Enter fullscreen mode Exit fullscreen mode

Pod 

Pod
├── Spring Boot Container
└── FluentBit Container
Enter fullscreen mode Exit fullscreen mode

Both share:

  • Storage
  • Network
  • Lifecycle

Deployment 

replicas: 5
Enter fullscreen mode Exit fullscreen mode

Ensures:

5 Healthy Pods
Enter fullscreen mode Exit fullscreen mode

always remain available.

If one Pod crashes:

Automatically Recreated
Enter fullscreen mode Exit fullscreen mode

If traffic spikes:

Scale to 10 Pods
Enter fullscreen mode Exit fullscreen mode

If deployment fails:

Rollback
Enter fullscreen mode Exit fullscreen mode

Interview Question

Why are Deployments preferred over Pods in production?

Answer:

Pods only run containers and provide a shared execution environment. They do not offer self-healing, scaling, rolling updates, or rollback capabilities. Deployments manage Pods and maintain the desired state of the application, making them the preferred choice for production workloads.

Quick Comparison

Feature Container Pod Deployment
Runs Application ✅ ✅ Indirectly
Smallest Kubernetes Object ❌ ✅ ❌
Contains Multiple Containers ❌ ✅ ❌
Shared Network ❌ ✅ ❌
Shared Storage ❌ ✅ ❌
Self-Healing ❌ ❌ ✅
Scaling ❌ ❌ ✅
Rolling Update ❌ ❌ ✅
Rollback ❌ ❌ ✅
Production Ready ❌ Rarely ✅

Key Takeaway

Remember this simple statement:

Containers run applications, Pods host containers, and Deployments manage Pods.

Or even simpler:

Container  = Application
Pod        = Home for Containers
Deployment = Pod Manager
Enter fullscreen mode Exit fullscreen mode

Once you understand this hierarchy, concepts like Services, Ingress, HPA, StatefulSets, DaemonSets, and Argo CD become much easier to understand.

Kubernetes #DevOps #CloudNative #Containers #Docker #K8s #SRE #PlatformEngineering #ArgoCD #LearningInPublic

Top comments (0)