Kubernetes Pods Explained: The Smallest Building Block

A quick recap, then the smallest piece

In Day 2 we traced the journey from “run my app” to a container actually starting on a worker node. We kept saying things like “copies of your app” without defining exactly what a copy is. Today we name it: the Pod.

This matters more than it sounds like it should. The Pod is the smallest unit Kubernetes schedules, scales, and manages. Not the container — the Pod. Get comfortable with this one idea and a surprising amount of Kubernetes terminology stops feeling arbitrary.

What a Pod actually is

A Pod is a thin wrapper around one or more containers, plus some shared resources those containers can use together. It’s the smallest deployable unit in Kubernetes — you can’t ask the cluster to run “just a container”; you always ask it to run a Pod.

Why wrap something that’s already a neat, self-contained unit? Because most of the time, a single container is the whole story — and Kubernetes makes that the common case. Most Pods hold exactly one container. When you read about a Pod running “your app,” picture one container, one Pod, most days.

But sometimes a couple of containers genuinely belong together — tightly enough that they should live and die as a unit, on the same machine, sharing the same local resources. That’s the less common case the Pod model also supports, and it’s worth seeing why.

What containers in a Pod actually share

When two or more containers land in the same Pod, they get two things in common that containers in different Pods never get:

The same network identity. Every Pod gets its own IP address. All containers inside that Pod share it — meaning they can reach each other simply by talking to localhost, exactly like two processes running on the same machine. A container in a different Pod can't take this shortcut; it has to reach the other Pod over the network properly (a topic we'll dig into on Day 6, when we cover Services).

The same storage volumes. A Pod can define storage that’s attached to it, and every container inside that Pod can read and write to that same storage. This makes it simple for containers in one Pod to hand files back and forth — say, one container writes logs and another reads and ships them elsewhere.

A common real pattern that uses this: a main application container paired with a small helper container sitting alongside it — for example, one that watches local files and forwards them to a logging system. The helper rides along in the same Pod specifically so it can share that Pod’s network and storage with no extra setup. This kind of “extra helper container in the same Pod” pattern is often called a sidecar. You don’t need to design one yourself today — just recognize the term when you see it, and know why it lives in the same Pod rather than its own.

Pods are meant to be temporary

Here’s the mindset shift that trips up almost everyone coming from older ways of running servers: Pods are designed to be disposable.

Get HackTrace’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Remember the “pets vs. cattle” idea from Day 1? Pods are the cattle. A Pod is not meant to be a long-lived, precious thing you patch and nurse for months. If a Pod’s node fails, or the Pod becomes unhealthy, Kubernetes doesn’t try to repair that exact Pod — it simply creates a brand-new replacement Pod elsewhere. The old one is gone for good, including anything that was only stored inside it.

This is the word ephemeral: short-lived, and expected to be replaced rather than restored. A few consequences fall directly out of this:

• A Pod’s IP address can change every time it’s replaced — which is precisely why Day 6’s Services exist, to give your app a stable address that doesn’t depend on any one Pod.
• Anything your app needs to keep, like database files, shouldn’t live only inside the Pod’s own temporary storage — that’s a problem solved later in the series with persistent storage.
• You’ll rarely, if ever, create a single standalone Pod by hand in real usage. Almost always, a higher-level controller (like the Deployment we’ll meet on Day 8) creates and replaces Pods for you automatically, applying that same “compare desired to actual” loop from Day 2 directly to Pods.

None of this means Pods are fragile or unreliable. It means the individual Pod isn’t where reliability comes from — the system around it is. You get resilience by accepting that any single Pod is replaceable, not by trying to keep one alive forever.

A first look at describing a Pod

Kubernetes objects are usually described in a file written in YAML, a simple, readable text format for structured data. You won’t write many raw Pod files by hand in practice, but seeing one demystifies everything that follows in the series, since this same shape reappears everywhere.

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

Read it almost like English: “Using API version v1, I want a Pod, named my-first-pod. Inside it, run one container called web, using the nginx image, version 1.27, and it listens on port 80."

That spec section — short for specification — is where you describe your desired state for this object. You're not issuing a command like "start this." You're describing the end result you want, and handing it to the API server, exactly as we walked through in Day 2. Kubernetes takes it from there.

Why this foundation matters going forward

Almost everything later in this series builds on top of the Pod without replacing the idea. A Deployment (Day 8) doesn’t run instead of Pods — it creates and manages Pods for you, watching the count and replacing any that disappear. A Service (Day 6) doesn’t avoid Pods — it gives a changing set of Pods one stable front door. Even storage and scaling, much further down the series, are really about giving Pods what they need to do their job reliably.

So when something in a later post says “Kubernetes scales your app to ten replicas,” you’ll now know exactly what’s multiplying: ten Pods, each one disposable, each one capable of being replaced in seconds, together forming an application that’s far more resilient than any single piece of it.

In Day 4, we step back up a level and look at how Kubernetes keeps large clusters organized — using namespaces to divide one cluster into separate, manageable spaces.

Key takeaway: A Pod — not a container — is the smallest thing Kubernetes actually runs; it’s intentionally temporary and replaceable, and nearly every other Kubernetes concept you’ll learn exists to manage, expose, or support Pods rather than to replace them.