Kubernetes PodsWhat a Pod is and how it works

One of the most important concepts when learning Kubernetes is the Pod.

When we learned Docker, we saw how to run a container from a Docker image.

For example:

docker run nginx

But running an application in Kubernetes works a little differently.

Here we don't create containers directly. Instead, we create a Kubernetes resource called a Pod.

In Kubernetes, a Pod is the smallest deployable unit, and one or more containers can run inside it.

In this tutorial, we will go step by step through what a Pod is, how Pods relate to containers, how scaling works, why multi-container Pods are used, and how to create a Pod with kubectl.

1. What needs to be ready before learning about Pods?

Before creating a Pod, we assume two things are already in place.

1. A Docker/container image of the application has been built.
2. A Kubernetes cluster is running.

Say you have built a Python or Node.js application.

It has now been packaged as a Docker image.

That image can be stored in a container registry.

For example:

• Docker Hub
• A private company registry
• Any other container image repository

Kubernetes can pull the image from that registry and run the container.

Basic application deployment flow

Application Source Code
          |
          ▼
      Dockerfile
          |
          ▼
    Container Image
          |
          ▼
   Container Registry
          |
          ▼
   Kubernetes Cluster
          |
          ▼
         Pod
          |
          ▼
    App Container

In other words, to run an application in Kubernetes, we usually need a container image and a working Kubernetes cluster.

2. What is a Kubernetes Pod?

A Pod is Kubernetes' smallest deployable unit.

Put simply:

A Pod is a Kubernetes object that groups one or more containers together.

Usually, a Pod contains a single application container.

Example:

Kubernetes Pod
      |
      ▼
┌─────────────────────┐
│        Pod          │
│                     │
│  ┌───────────────┐  │
│  │ Nginx         │  │
│  │ Container     │  │
│  └───────────────┘  │
│                     │
└─────────────────────┘

Here, the Nginx container is running inside a Pod.

Kubernetes manages this Pod as a deployable unit.

In other words, when running an application in Kubernetes, we usually create a Pod, and the container runs inside that Pod.

3. Kubernetes does not deploy containers directly

This is an important Kubernetes concept.

With Docker, we can run a container directly.

Docker example

docker run nginx

This command creates and runs an Nginx container through Docker Engine.

But in Kubernetes:

kubectl run nginx --image=nginx

This command creates a Pod.

The Nginx container runs inside the Pod.

Docker vs Kubernetes execution

Docker
  |
  ▼
Container
  |
  ▼
Nginx Application

Kubernetes
    |
    ▼
   Pod
    |
    ▼
Container
    |
    ▼
Nginx Application

The key difference here:

Docker's main runtime object is the container.

Kubernetes' smallest deployable workload unit is the Pod.

Kubernetes manages the Pod's desired state and has the container runtime execute the Pod's containers.

4. The relationship between Pods and containers

Usually, a Pod contains one application container.

We can think of this as the one Pod to one application container pattern.

Example:

Pod 1
  └── Application Container 1

Pod 2
  └── Application Container 2

Pod 3
  └── Application Container 3

Say you want to run a web application.

If you first create one Pod:

Pod 1
  |
  └── Web Application

Now, if you want to run three instances of the same application, you usually use three Pods.

Pod 1 → Web App Container
Pod 2 → Web App Container
Pod 3 → Web App Container

Here, three instances of the same application are running in three separate Pods.

Important: to scale an application, you usually don't keep several copies of the same application container inside one Pod.

Instead, you create new Pods.

5. How does Pod scaling work in Kubernetes?

Say you have a web application.

At first, the application gets little traffic.

So one Pod is enough.

Kubernetes Node 1
       |
       ▼
     Pod 1
       |
       ▼
Web App Container

But after a while, the application's users grow.

Now one Pod cannot handle all the requests.

So the application needs more instances.

In Kubernetes, an application is usually scaled by creating more Pods.

Example: from one Pod to three Pods

              Node 1
                 |
       +---------+---------+
       |         |         |
       ▼         ▼         ▼
     Pod 1     Pod 2     Pod 3
       |         |         |
       ▼         ▼         ▼
     Web App   Web App   Web App

Now three instances of the same application are running.

This makes it possible to distribute the application's traffic across multiple Pods, as long as an appropriate Service and load distribution are configured.

Scaling across multiple nodes

Say Node 1 doesn't have enough CPU or memory.

Then the Kubernetes scheduler can schedule the new Pod on another available node.

           Kubernetes Cluster
                   |
        +----------+----------+
        |                     |
        ▼                     ▼
      Node 1                Node 2
        |                     |
    +---+---+             +---+---+
    |       |             |       |
    ▼       ▼             ▼       ▼
   Pod 1   Pod 2         Pod 3   Pod 4
    |       |             |       |
   App     App           App     App

With this architecture, Kubernetes can distribute application workloads across multiple nodes.

Of course, the nodes' available resources and Kubernetes' scheduling rules have to allow it.

Remember

The usual way to scale an application in Kubernetes is to create new Pods, not to add more application containers to the same Pod.

6. Scaling up and scaling down

In Kubernetes, increasing or decreasing the number of running instances of an application is called scaling.

Scaling up

Scaling up means increasing the number of running Pod instances of an application.

Example:

Before:
  Pod 1
  Total: 1 Pod

After:
  Pod 1
  Pod 2
  Pod 3
  Total: 3 Pods

This lets the application handle more traffic, as long as the application and infrastructure are designed for it.

Scaling down

Scaling down means reducing the number of running Pods.

Example:

Before:
  Pod 1
  Pod 2
  Pod 3
  Pod 4
  Pod 5
  Total: 5 Pods

After:
  Pod 1
  Pod 2
  Total: 2 Pods

When traffic drops, removing the extra Pods saves infrastructure resources.

Important: in production, application scaling is usually managed through a Deployment or another workload controller.

A standalone Pod does not maintain multiple replicas by itself.

7. Can a Pod contain multiple containers?

Yes, it can.

Several containers can run inside one Pod.

But this is usually not done to run multiple instances of the same application.

Instead, a multi-container Pod is used when two containers are closely connected and need to work together.

Example:

┌──────────────────────────────┐
│             Pod              │
│                              │
│  ┌────────────────────────┐  │
│  │ Main Web Application   │  │
│  └────────────────────────┘  │
│                              │
│  ┌────────────────────────┐  │
│  │ Helper Container       │  │
│  └────────────────────────┘  │
│                              │
└──────────────────────────────┘

Here, one container runs the main application.

The other container supports that application.

A helper container's job could be to:

• Process uploaded files
• Collect application logs
• Fetch external data
• Support the main application
• Synchronize files or content
• Provide sidecar functionality

This pattern is often called the sidecar pattern.

8. Why put multiple containers in one Pod?

The main reason to use a multi-container Pod is so that closely related containers can share some resources.

Containers in the same Pod usually share:

• The network namespace
• Pod-level networking
• Shared volumes, if configured
• The Pod lifecycle boundary

This makes it easy for the containers to communicate with each other.

Shared network

Containers in the same Pod usually share the same network namespace.

So they can communicate using localhost.

Example:

               Pod
                |
       +--------+--------+
       |                 |
       ▼                 ▼
 Main Application    Helper Container
    Port 8080            Port 9000
       |                 |
       +------localhost--+

Say the main application runs on port 8080.

The helper container, from inside the same Pod, can talk to the main application at localhost:8080.

Shared storage

Multiple containers in the same Pod can mount the same volume.

Example:

                 Pod
                  |
          +-------+-------+
          |               |
          ▼               ▼
    App Container    Helper Container
          |               |
          +-------+-------+
                  |
                  ▼
             Shared Volume

In this case, when the main application writes a file, the helper container can read that file from the same shared volume.

Volume sharing does not happen automatically, though. You have to configure the volume and volume mounts in the Pod specification.

Shared lifecycle

When a Pod is created, Kubernetes tries to run the containers according to the Pod's spec.

When a Pod is deleted, its containers are terminated too.

But there is no guarantee that all containers in the same Pod start or stop at exactly the same moment.

Each container's restart and readiness behavior can differ.

9. Why use a Pod instead of managing helper containers by hand?

Say you are running an application and a helper container with plain Docker, without Kubernetes.

Your setup might look like this:

App Container 1 ↔ Helper Container 1
App Container 2 ↔ Helper Container 2
App Container 3 ↔ Helper Container 3

Here, each application container needs its own helper container.

Now you have to manage by hand:

• Container networking
• Container communication
• Shared volumes
• Matching each application with its helper container
• Restart behavior
• Container cleanup
• Container lifecycle coordination

As application instances grow, this management becomes even more complex.

Kubernetes Pods make this easier by grouping related containers into one logical unit.

Example:

              Kubernetes
                  |
        +---------+---------+
        |         |         |
        ▼         ▼         ▼
       Pod 1     Pod 2     Pod 3
        |         |         |
      App +     App +     App +
      Helper    Helper    Helper

Here, each Pod groups the main application and its helper container together.

10. What does Kubernetes manage for containers in the same Pod?

Through the Pod, Kubernetes gives related containers a shared execution environment.

Example

Kubernetes Pod
      |
      ├── Shared Network
      |
      ├── Shared Volumes
      |
      ├── Main Application Container
      |
      └── Helper Container

As a result, related containers can be defined in the same Pod instead of being connected separately.

11. Are multi-container Pods common?

Multi-container Pods are a valid and useful Kubernetes feature.

But at the beginner level, the most common pattern is:

One Pod
   |
   ▼
One Application Container

And the multi-container pattern:

One Pod
   |
   ├── Main App Container
   |
   └── Helper Container

For now, most examples in this course will use single-container Pods.

That makes the basic Kubernetes concepts easier to understand.

Sidecar containers and multi-container Pod architecture can be covered in more detail later.

12. Creating a Pod with kubectl

Now let's create a real Kubernetes Pod.

We will use the Nginx image.

Step 1: Check the Kubernetes cluster

First, make sure the cluster is running.

If you use Minikube:

minikube status

Then:

kubectl get nodes

Expected example:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   5m    v1.x.x

Step 2: Create the Nginx Pod

kubectl run nginx --image=nginx

This command tells Kubernetes:

Create a Pod named nginx, and run a container inside that Pod using the nginx image.

Kubernetes pulls the Nginx image according to the default registry configuration. Usually, that means pulling it from Docker Hub.

Architecture

kubectl run nginx --image=nginx
              |
              ▼
      Kubernetes API Server
              |
              ▼
           Pod Created
              |
              ▼
        Kubernetes Node
              |
              ▼
        Container Runtime
              |
              ▼
       Nginx Container

13. Listing Kubernetes Pods

After creating the Pod, check:

kubectl get pods

At first, you may see output like this:

NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          5s

After a while:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          20s

The important columns here:

READY 1/1 means one of the Pod's one container is ready.

Running means the Pod has been bound to a node and its container process is running.

14. Pod status — ContainerCreating vs Running

After creating a Pod, you may see different statuses.

ContainerCreating

Example:

NAME    READY   STATUS              RESTARTS
nginx   0/1     ContainerCreating   0

In this state, Kubernetes is preparing to start the container.

This can include:

• Pulling the container image
• Creating the container
• Setting up the network
• Mounting storage
• Container runtime preparation

Running

Example:

NAME    READY   STATUS    RESTARTS
nginx   1/1     Running   0

Here, the Pod's container is running and ready.

But you should not assume the application is fully healthy just because the status is Running.

To check application health more reliably, you can use readiness probes and liveness probes.

These will be covered later in the Kubernetes health check topic.

15. Can external users reach a Pod as soon as it is created?

Usually not.

When you create a Pod in Kubernetes, the application runs inside the cluster.

But the application does not automatically become accessible to external users.

Example:

Kubernetes Cluster
        |
        ▼
       Pod
        |
        ▼
   Nginx Container

Even with the container running, reaching it directly from a browser needs the right networking configuration.

To expose an application, you can use Kubernetes networking resources such as a Service.

External User
      |
      ▼
    Service
      |
      ▼
     Pod
      |
      ▼
   Container

Services and Kubernetes networking are not covered in detail in this tutorial.

For now, our focus is:

creating a Pod and verifying that it is running.

16. A simple mental model of a Pod

You can think of a Pod as a small box or wrapper.

Pod       = Box
Container = Application inside the Box

Usually:

┌─────────────────────┐
│        Pod          │
│                     │
│    ┌───────────┐    │
│    │ Container │    │
│    └───────────┘    │
│                     │
└─────────────────────┘

That is, one application container inside one box.

Sometimes:

┌─────────────────────────────┐
│             Pod             │
│                             │
│    ┌──────────────────┐     │
│    │ Main Application │     │
│    └──────────────────┘     │
│                             │
│    ┌──────────────────┐     │
│    │ Helper Container │     │
│    └──────────────────┘     │
│                             │
└─────────────────────────────┘

That is, a main application and a helper container inside one box.

Kubernetes manages this box, the Pod, as one logical deployable unit.

17. Docker container vs Kubernetes Pod

Docker example

docker run nginx

Kubernetes example

kubectl run nginx --image=nginx

Docker runs a container.

Kubernetes creates a Pod, and the container runs inside it.

18. The full Kubernetes Pod workflow

Now let's look at the whole process together.

1. Build Application Image
        |
        ▼
2. Push Image to Registry
        |
        ▼
3. Start Kubernetes Cluster
        |
        ▼
4. Create Pod
        |
        ▼
5. Kubernetes Schedules Pod
        |
        ▼
6. Node Pulls Container Image
        |
        ▼
7. Container Runtime Starts Container
        |
        ▼
8. Pod Status Becomes Running
        |
        ▼
9. Verify Pod Using kubectl

This workflow is important for understanding how Kubernetes executes a Pod.

19. Important kubectl commands

20. Complete hands-on demo — an Nginx Pod

All the commands from this tutorial together:

# 1. Check Minikube Cluster
minikube status

# 2. Check Kubernetes Nodes
kubectl get nodes

# 3. Create Nginx Pod
kubectl run nginx --image=nginx

# 4. List Pods
kubectl get pods

# 5. Check Specific Pod
kubectl get pod nginx

# 6. Get Pod Details
kubectl describe pod nginx

# 7. Check Container Logs
kubectl logs nginx

# 8. Delete Pod After Testing
kubectl delete pod nginx

With these commands, we can create, inspect and delete a Kubernetes Pod.

21. Final takeaway — Kubernetes Pods

The most important thing in this tutorial is understanding the relationship between Pods and containers.

In Kubernetes, application containers are usually not deployed directly.

Containers run inside a Pod.

The Pod is Kubernetes' smallest deployable unit.

Usually, a Pod contains one application container.

When scaling an application, you usually create more Pods.

And when multiple containers are closely connected to each other, they can run in the same Pod.

Quick recap

Kubernetes
    |
    ▼
   Pod
    |
    ▼
Container
    |
    ▼
Application

Scaling:

Application
    |
    ▼
Multiple Pods
    |
    ├── Pod 1 → Container
    |
    ├── Pod 2 → Container
    |
    └── Pod 3 → Container

Multi-container Pod:

Pod
 |
 ├── Main Application Container
 |
 └── Helper Container

Final one-line summary:

A Kubernetes Pod is the smallest deployable unit, and one or more containers run inside it. Usually a Pod holds one application container, and to scale an application you create new Pods instead of adding more containers to the same Pod.