Day 2/30 — If Kubernetes runs containers, why did it invent Pods?

Imagine you book an Uber.

You never ask for a specific car engine. You don’t care about the tire brand. You don’t even choose the driver.

You simply request one ride.

The app decides everything else.

Kubernetes works in a very similar way.

Most people think Kubernetes manages containers.

It doesn’t.

It manages Pods.

That distinction is one of the first things every SRE should understand.

🏠 Let’s use an analogy.

Imagine an apartment building.

• The building is a Node
• The family living inside is a Pod
• Each family member is a Container

Normally, one family lives in one apartment.

Likewise, most Pods contain just one application container.

But sometimes a family needs extra help.

Maybe a security guard.

Maybe a housekeeper.

Maybe an elderly grandparent.

They all live in the same apartment because they share the same kitchen, electricity, Wi-Fi, and address.

That’s exactly why Pods exist.

Containers inside a Pod share:

✅ The same network namespace (same IP address)

✅ The same storage volumes

✅ The same lifecycle

They are designed to work together.

Why didn’t Kubernetes just manage containers?

Because production systems are rarely made of isolated processes.

Imagine your application writes logs.

Should your application also upload logs to Splunk?

It could…

But a cleaner design is to run another container dedicated to collecting logs.

Now you have:

• Application Container
• Log Collector Container

Both need to:

• Start together
• Stop together
• Share the same storage
• Communicate over localhost

A Pod provides exactly that.

This pattern is called the Sidecar Pattern, and it’s widely used in production for log forwarding, service meshes, proxies, and monitoring agents.

A production example

Picture this.

Your payment service is running.

Alongside it is another container responsible for exporting Prometheus metrics.

If the payment service crashes but the metrics exporter keeps running…

Your monitoring becomes misleading.

Likewise, if the metrics exporter crashes, the application loses observability.

They are one operational unit.

That’s why Kubernetes schedules, starts, restarts, and replaces them together inside a Pod.

Common misconception

People often say:

“I have three containers running.”

An SRE usually thinks:

“I have three Pods running.”

Because Pods are not container they are Kubernetes smallest deployable unit.

Quick commands

kubectl get pods

kubectl describe pod <pod-name>

kubectl logs <pod-name>

kubectl exec -it <pod-name> -- sh

Try running kubectl describe pod.

Notice how Kubernetes reports information about the Pod first, then the containers inside it.

That’s a subtle but important design choice.

Interview Question

Why can’t two Pods share the same IP address?

Hint:

Pods are designed to be independently deployable and routable.

We’ll explore Kubernetes networking later in this series.

Production Takeaway

If you’re troubleshooting Kubernetes, think in terms of Pods — not containers.

Pods are the unit Kubernetes schedules, monitors, restarts, and replaces.

Once that mental model clicks, many Kubernetes concepts become much easier to understand.

📘 Production Engineering Explained — Day 2/30

Tomorrow:

Why Kubernetes never creates Pods directly — and why Deployments exist.

Kubernetes #DevOps #SRE #CloudComputing #PlatformEngineering #Containers #SoftwareEngineering #LearningInPublic