To understand any idea, first understand the problem that made someone invent it.

A quick look at containers

A container is a sealed package holding an application together with everything it needs to run, such as its libraries and settings. Because the package is sealed, it behaves the same on a laptop, a test server or a giant cloud machine. Containers start in seconds and use little memory.

Kubernetes is a system that runs and manages containers across many computers, and each computer in the group is called a node. A natural guess would be that Kubernetes manages containers directly. It does not, and the reason is worth understanding.

Programs that need a close companion

Real applications are rarely alone. A web server may need a small helper that copies its log files to a central place. A program may need a tiny setup task that prepares files before it starts. A database may need a helper that takes regular backups. These helpers must always live on the same computer as the main program, share its files and talk to it instantly.

If Kubernetes managed each container separately, one could land on Node 1 and its helper on Node 7. They would lose their close connection. Kubernetes needs a way to say: “These containers are a team. Keep them together, always.”

A wrapper that also hides messy details

Different container tools have their own ways of handling networking and storage. Kubernetes wanted one simple unit that hides those differences. The pod is that unit: a common wrapper with one address, one shared storage arrangement and one lifecycle, no matter which container tool sits underneath.

A pod is the smallest unit you can create and manage in Kubernetes: a group of one or more containers that share a network identity and storage, and always run together on the same node.

Let us unpack that. Smallest unit means Kubernetes cannot schedule half a pod or a single container on its own. The pod is the atom. Share a network identity means all containers in the pod use the same IP address and can reach each other through the name localhost. Share storage means the pod can define folders, called volumes, that every container inside can read and write. Run together on the same node means the pod is never split across machines.

The pod in one picture

flowchart TB
  subgraph NODE[Worker Node]
    subgraph POD[Pod with one IP address]
      C1[Main container]
      C2[Helper container]
      VOL[(Shared volume)]
    end
  end
  C1 --- VOL
  C2 --- VOL
  C1 |localhost| C2
        

The four big facts about every pod

Four words that beginners mix up. A clear map removes the confusion.

Pod versus virtual machine

A pod is sometimes described as a “logical host” because the containers inside behave a little like programs running on the same small computer. That is the reason for sharing the address and the storage. But unlike a virtual machine, a pod does not carry its own operating system. It is far lighter, starts in seconds and is meant to be thrown away without ceremony.

Pod versus container

The container is the workhorse and the pod is its supervisor’s office. Kubernetes talks about pods when it schedules, scales and gives addresses. It talks about containers only when it looks inside a pod at the individual programs.

The magic of a pod is not the box itself but what its containers share, and what they keep private.

Linux, the operating system that runs most containers, uses features called namespaces to separate programs from each other. A namespace is like a wall around a private space: what is inside cannot see what is outside. A pod decides which walls to build and which to leave out between its containers.

The hidden anchor: the pause container

When a pod starts, the container runtime first creates a tiny, invisible helper often called the pause container or pod sandbox. Its only job is to hold the network space, the pod’s address, so that the real containers can join it. Even if an application container crashes and restarts, the pause container remains, and the pod keeps the same address.

What the pod specification describes

When you create a pod you write a short document called a manifest, usually in a text format called YAML. It states which containers to run, which images to use, which ports they listen on, what settings and volumes they need and how much memory they may use. Kubernetes reads it and works to make it true. The pod is thus a description first and a running thing second.

flowchart LR
  M[Pod manifest] --> API[API Server stores it]
  API --> S[Scheduler picks a node]
  S --> K[kubelet on that node]
  K --> R[Container runtime]
  R --> P[Running pod]
        

Eight terms that appear in almost every conversation about pods.

Labels: the sticky notes that hold Kubernetes together

Pods change constantly, so Kubernetes cannot connect things by pod names. It connects them by labels. A Service says “send traffic to all pods labelled app equals payments,” and every matching pod automatically joins the group, new or old. Labels are the glue that lets a sea of temporary pods behave like one steady application.

Most pods hold one container. A smaller number hold a team, and that team follows well-known patterns.

The everyday case: one container per pod

The overwhelming majority of pods contain a single application container. This is the simplest and cleanest design. Each pod is independent, scales alone and is easy to reason about. If you are unsure, choose one container per pod.

When a team makes sense

Extra containers belong in a pod only when they are tightly coupled to the main program, meaning they must share its address or files and must live and die with it. Several standard patterns describe this.

flowchart LR
  subgraph POD[Pod]
    INIT[Init container prepares files] --> MAIN[Main application container]
    MAIN  SIDE[Sidecar ships logs]
  end
  SIDE --> LOGS[Central log system]
        

Many components cooperate to bring a pod to life. Let us follow the whole story.

sequenceDiagram
  participant U as You
  participant A as API Server
  participant E as etcd
  participant S as Scheduler
  participant K as kubelet on Node
  participant R as Container Runtime
  U->>A: Submit pod description
  A->>E: Save pod record
  A-->>U: Pod accepted
  S->>A: Any pod without a node?
  A-->>S: Yes, this pod
  S->>A: Assign the best node
  K->>A: Any pod assigned to me?
  A-->>K: Yes, start this pod
  K->>R: Create sandbox and pull images
  R-->>K: Containers started
  K->>A: Report pod status
        

A pod has a simple life story with a small number of chapters.

The five pod phases

The phase is a short summary of where the pod is in its life. It is intentionally coarse. For details, you look at the container states and conditions.

stateDiagram-v2
  [*] --> Pending
  Pending --> Running: containers started
  Running --> Succeeded: all exited with success
  Running --> Failed: a container failed and no restart
  Running --> Unknown: node contact lost
  Succeeded --> [*]
  Failed --> [*]
        

The three container states

Pod conditions: the checklist behind the phase

Alongside the phase, a pod carries conditions such as whether it has been scheduled, whether its containers are ready and whether it is fully ready to serve. A pod may be in the Running phase yet not Ready, and only Ready pods receive traffic from Services.

Networking is where pods truly differ from plain containers.

Every pod gets a real address

When a pod starts, the network plugin, known as the CNI plugin, assigns it an IP address that is unique across the whole cluster. Any pod can reach any other pod directly using that address, with no complicated translation in between. This simple promise is called the flat network model.

Inside the pod: localhost

Containers within the same pod share the same network space. If a main container listens on port 8080, its sidecar can reach it at localhost on port 8080. Because they share one set of ports, two containers in the same pod cannot listen on the same port.

flowchart LR
  subgraph PA[Pod A address 10.1.0.5]
    A1[App container port 8080]
    A2[Sidecar container]
  end
  subgraph PB[Pod B address 10.1.1.9]
    B1[Other app]
  end
  A2 -->|localhost 8080| A1
  A1 -->|pod address| B1
        

Pod addresses are temporary

A replacement pod gets a new address. This is why applications should not memorise pod addresses. Instead, they use a Service, which provides one steady name and address in front of a changing group of pods, selected by labels. A helper program named kube-proxy on each node keeps the rules for those Services up to date.

A container’s own files disappear when it restarts. Volumes exist to fix that.

The problem with container files

Whatever a container writes into its own file system belongs only to that container’s life. If the container crashes and is restarted, it starts again from a clean image, and the written files are gone. And if the whole pod is replaced, its storage goes with it unless you planned otherwise.

Volumes to the rescue

A volume is a folder defined at pod level, which containers mount at chosen paths. It outlives individual container restarts within the pod, and it can be shared between containers in the same pod. Kubernetes supports many kinds.

flowchart TB
  subgraph POD[Pod]
    W[Writer container]
    R[Reader container]
    V[(emptyDir volume)]
  end
  W -->|writes files| V
  V -->|reads files| R
  POD -.->|persistent needs| PVC[Persistent volume claim]
  PVC --> DISK[(Cloud disk)]
        

A running program is not always a working program. Probes let Kubernetes look inside.

A probe is a small regular check that the kubelet performs on a container. It may send a web request, try to open a network connection or run a short command inside the container. The answer decides what Kubernetes does next.

When something goes wrong, the pod’s status usually tells you exactly what.

Restart policy

Each pod carries a rule for what to do when a container stops. Always, the default, restarts it no matter why it stopped, and suits long-running services. OnFailure restarts only when the container exits with an error, and suits jobs. Never leaves finished or failed containers alone. Importantly, these restarts happen inside the same pod on the same node, by the kubelet.

The back-off delay

If a container keeps crashing, the kubelet does not restart it in a frantic loop. It waits a little longer between each try, doubling the delay each time up to a limit of about five minutes. This protects the node from a runaway crash cycle.

Status messages every beginner meets

A node has limited memory and processing power. Pods must declare how much they need.

For each container, you can state two numbers for processor time and memory. A request is what the container needs to run properly, and the scheduler uses it to find a node with enough room. A limit is the most the container may use. A container that crosses its memory limit is stopped, while one that crosses its processor limit is slowed down.

Quality of Service classes

Based on how requests and limits are set, Kubernetes sorts each pod into one of three classes. When a node runs short of memory, the least protected pods are removed first.

The scheduler is a matchmaker between pods that need homes and nodes that have room.

For each new pod, the scheduler first filters nodes, dropping those that cannot host it, and then scores the rest to pick the best. You can guide this process with several tools.

flowchart LR
  P[New pod] --> F[Filter nodes that cannot host it]
  F --> S[Score the remaining nodes]
  S --> B[Pick the highest score]
  B --> N[Bind pod to that node]
        

Static pods: a special case

Most pods are created through the API server and scheduled. Static pods are different: they are defined as files on a particular node, and the kubelet on that node starts and watches them directly. Kubernetes uses this method to run its own control plane components in some clusters.

A good ending matters as much as a good beginning, especially during updates.

When a pod is deleted, Kubernetes does not simply cut power. It follows a polite sequence so that ongoing work has time to finish.

sequenceDiagram
  participant U as You or Controller
  participant A as API Server
  participant K as kubelet
  participant C as Container
  U->>A: Delete the pod
  A->>A: Mark pod as Terminating
  A-->>K: Stop this pod
  Note over A: Pod removed from Service traffic
  K->>C: Run preStop hook if defined
  K->>C: Send termination signal
  Note over K,C: Grace period, default 30 seconds
  K->>C: Force kill if still running
  K->>A: Pod fully gone
        

A pod is mortal. If nobody watches over it, its death is permanent.

A pod created directly, with no manager, is called a bare pod. If its node fails, or someone deletes it, or it is evicted, nothing brings it back. The pod does not heal itself, move itself or multiply itself. Pods are also mostly immutable: you cannot change most of their settings in place. To change a pod substantially, you replace it.

That is why real applications use controllers, which are managers that create pods from a template and keep the right number alive.

flowchart TB
  D[Deployment] --> RS[ReplicaSet]
  RS --> P1[Pod 1]
  RS --> P2[Pod 2]
  RS --> P3[Pod 3]
  P2 -. crashes .-> X[Replaced by a new pod]
        

Pods run your code, so pod settings are the first line of defence.

Pods appear and vanish, so you must capture their story before they disappear.

Every design has strengths and costs, and the pod is no exception.

How many containers per pod?

The rule of thumb is simple. Put containers in the same pod only if they must scale together, must share a network address or files, and must always run side by side. If any of those is false, use separate pods connected by a Service.

Habits that experienced teams follow, and traps they learned to avoid.

Helpful patterns

Traps to avoid

Theory feels clearer when you see pods doing real jobs.

Well-known organisations have publicly described running huge numbers of pods. The Kubernetes project documents support for clusters of up to 5,000 nodes and well over a hundred thousand pods, and its default guideline is a maximum of around 110 pods per node, though real limits depend on the machine and configuration.

Simple habits that prevent most early pain.

No. A container is one packaged application. A pod is a wrapper that holds one or more containers and gives them a shared address and storage. Most pods contain a single container, which is why people confuse the two.

No. A pod is always placed on exactly one node, and all its containers run there together. To spread work across nodes, you run several pods.

Because a replacement is a brand new pod, not a repair of the old one. Applications should connect through Services, which offer a stable name and address in front of the changing pods.

Data stored in the container’s own files or in an emptyDir volume is lost. Data on persistent volumes remains, and can be attached to a new pod. That is why databases use persistent storage.

Yes, according to the pod’s restart policy. With the default policy, the kubelet restarts the container on the same node, with growing delays between attempts if it keeps crashing.

No. Only pods owned by a controller are recreated. That is the main reason for using Deployments and similar objects.

Only a small number of fields, such as container images, can be updated in place. Most changes require replacing the pod, which is why controllers roll out changes by creating new pods and retiring old ones.

Usually the scheduler cannot find a suitable node because of insufficient resources, unmet placement rules or unavailable storage. Describing the pod shows the reason in its events.

Through localhost, because they share the same network space, or through shared volumes and shared memory. They must use different ports.

A pod is a single running unit. A Deployment is a manager that keeps a chosen number of identical pods alive and handles rolling updates. You describe the pod template inside the Deployment.

Not at all, if the containers are a genuine team that must share an address, files and lifecycle, as with a sidecar. It becomes a mistake when unrelated programs are grouped only for convenience.

A pod is the smallest deployable unit in Kubernetes: a small home for one or more containers that share a network address, storage volumes and a lifecycle, and always run together on a single node. It exists because real programs sometimes need close companions, and because Kubernetes needed one simple wrapper that hides the differences between container tools.

Around this core idea sits a complete story: how a pod is created through the API server, scheduler and kubelet, how it moves through phases and states, how probes judge its health, how resources and placement rules shape where it lands, and how it shuts down politely. Because pods are disposable, they are almost always managed by controllers, connected through Services and given persistent storage when data must last.

Keep the hotel room picture in mind. Guests check into rooms, not into beds. The room gives them an address, shared facilities and a fixed checkout time, and when the stay ends, the room is cleaned and reused. Treat your pods the same way: use them freely, and never get attached to a particular one.