If you understand Pods properly, Deployments, Services, scaling, networking, and troubleshooting will become much easier.

1. What exactly is a Pod?#

The official concept is:

A Pod is the smallest deployable unit in Kubernetes.

A Pod contains one or more containers that are managed together.

The most common case is:

Pod
└── Container

For example:

Pod: node-api
└── Node.js container

But a Pod can also contain multiple containers:

Pod
├── Application container
└── Sidecar container

2. Why doesn't Kubernetes directly manage containers?#

This is an important question.

You might think:

"If Docker/containerd already runs containers, why did Kubernetes create Pods?"

Because Kubernetes wants a unit that represents a group of tightly coupled containers sharing certain resources and lifecycle characteristics.

A Pod provides:

• Shared network
• Shared IP address
• Shared storage volumes
• Shared lifecycle
• A unit that Kubernetes schedules onto a node

So Kubernetes doesn't normally think:

Run container A on Node 1.

It thinks:

Run Pod X on Node 1.

Then the Pod contains the container(s).

3. Pod Analogy#

Think of a Pod like an apartment.

Apartment
├── Person A
└── Person B

The people share the apartment's:

• Address
• Certain resources
• Environment

Similarly:

Pod
├── Container A
└── Container B

Containers in the same Pod share:

• Network namespace
• Pod IP
• Volumes, when configured
• Lifecycle/scheduling boundary

4. One Container per Pod?#

You'll often see:

Pod
└── Container

That's because Kubernetes commonly uses:

One main application container per Pod.

For example:

Pod
└── Node.js API

Then scaling becomes simple:

3 Pods
=
3 Node.js application instances

5. Multiple Containers in a Pod#

Sometimes containers need to work extremely closely together.

Example:

Pod
├── Node.js API
└── Logging sidecar

The sidecar might collect or process logs.

Another example:

Pod
├── Application
└── Proxy

The important concept is:

Containers in the same Pod are co-located and share the Pod's network identity.

6. Containers in the Same Pod Share a Network#

Suppose:

Pod
├── Container A
└── Container B

They share the same network namespace.

Therefore they can communicate through:

localhost

For example:

Container A
   ↓
localhost:8080
   ↓
Container B

This is very different from two separate Pods.

7. Same Pod vs Different Pods#

Same Pod#

Pod
├── A
└── B

A can communicate with B using:

localhost:<port>

Different Pods#

Pod A              Pod B
  │                  │
  └──── network ─────┘

They communicate through the Kubernetes network, usually using Pod IPs or, more commonly for stable communication, a Service.

We'll study Services later.

8. Pod IP Address#

Every Pod normally receives its own IP address.

For example:

Pod A → 10.244.0.10
Pod B → 10.244.0.11
Pod C → 10.244.0.12

You can see the IP using:

kubectl get pods -o wide

Example:

NAME    READY   STATUS    IP            NODE
api     1/1     Running   10.244.0.10   node-1
web     1/1     Running   10.244.0.11   node-2

9. Important: Pod IPs are Ephemeral#

This is extremely important.

Don't assume:

api → 10.244.0.10

will always remain true.

If the Pod is deleted and recreated:

Old Pod
10.244.0.10
   ↓
Deleted
 
New Pod
10.244.0.25

The IP may change.

That's one reason we use Services.

We'll cover that in Chapter 7.

10. Creating a Pod Imperatively#

You already saw:

kubectl run nginx --image=nginx

This creates a Pod.

Check it:

kubectl get pods

Example:

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

11. Creating a Pod Declaratively#

In real Kubernetes work, you'll frequently use YAML.

Create:

apiVersion: v1
kind: Pod
 
metadata:
  name: nginx
 
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Save as:

pod.yaml

Then:

kubectl apply -f pod.yaml

Check:

kubectl get pods

12. Understanding Pod YAML#

Let's break it down.

apiVersion#

apiVersion: v1

Specifies the API version for the resource.

For a basic Pod:

v1

kind#

kind: Pod

Tells Kubernetes:

I am creating a Pod.

metadata#

metadata:
  name: nginx

Provides identifying information.

Here:

Name = nginx

spec#

spec:

Defines the desired configuration of the Pod.

containers#

containers:
  - name: nginx
    image: nginx:latest

Defines the container(s) inside the Pod.

13. containerPort#

You may see:

ports:
  - containerPort: 80

This documents that the container is expected to use port 80.

Important:

containerPort does not automatically expose the application outside the cluster.

We'll use a Service to expose applications.

14. Pod Lifecycle#

Pods have a lifecycle.

A simplified view:

Pending
   ↓
Running
   ↓
Succeeded

or:

Pending
   ↓
Running
   ↓
Failed

Let's understand these.

15. Pending#

When a Pod is:

Pending

it means it hasn't reached the running state yet.

Possible reasons include:

• Waiting for scheduling
• Insufficient CPU
• Insufficient memory
• Image pulling
• Volume problems
• Scheduling constraints

Example:

NAME   READY   STATUS
api    0/1     Pending

You would investigate with:

kubectl describe pod api

Especially check the Events section.

16. Running#

STATUS
Running

means the Pod has been successfully placed on a node and its containers are running or in the process of being started.

Example:

api   1/1   Running

17. Succeeded#

A Pod can complete successfully.

For example, a one-time task:

Run database migration
      ↓
Task completes
      ↓
Succeeded

This is more common with Jobs than long-running web applications.

18. Failed#

If the containers terminate unsuccessfully and Kubernetes doesn't restart them into a successful state according to the Pod's configuration, the Pod can end up in a failed state.

For example:

Run script
   ↓
Error
   ↓
Failed

19. What is CrashLoopBackOff?#

You'll encounter this constantly in Kubernetes troubleshooting.

Suppose your application starts:

Application starts
      ↓
Application crashes
      ↓
Kubernetes restarts it
      ↓
Application crashes again
      ↓
Restart
      ↓
Crash

Kubernetes gradually backs off between restart attempts.

You may see:

CrashLoopBackOff

It essentially tells you:

The container keeps crashing and Kubernetes is repeatedly trying to restart it with increasing delays.

Debug it using:

kubectl logs <pod>

and:

kubectl describe pod <pod>

20. kubectl logs --previous#

This is extremely useful for crashing containers.

Suppose the container:

starts → crashes → restarts

You can inspect the logs from the previous container instance:

kubectl logs <pod> --previous

This can reveal why the previous process crashed.

21. Pod Restart Policy#

Pods have a restart policy.

Common values:

Always
OnFailure
Never

Always#

Restart the container when it terminates.

Common for long-running workloads.

OnFailure#

Restart when the container exits unsuccessfully.

Never#

Don't restart the container automatically.

We'll explore this more when we study Jobs and Deployments.

22. Pod vs Deployment#

This is very important.

You might create:

Pod
└── Node.js

But if that Pod dies, you don't necessarily have the robust application management you'd want.

Instead, production applications usually use:

Deployment
    ↓
ReplicaSet
    ↓
Pods

For example:

Deployment
    ↓
ReplicaSet
    ↓
┌───────┬───────┬───────┐
Pod 1   Pod 2   Pod 3

The Deployment says:

"I want 3 copies."

The controllers work to maintain that state.

23. Why We Usually Don't Create Pods Directly#

Imagine you manually create:

Pod 1
Pod 2
Pod 3

What happens when Pod 2 dies?

You would have to manage the replacement yourself.

Instead:

Deployment
    ↓
Desired replicas = 3
    ↓
Pod 1
Pod 2
Pod 3

If Pod 2 disappears:

Pod 1
Pod 3

Kubernetes works toward:

Pod 1
Pod 3
Pod 4

This is why Deployments are normally used for stateless applications.

24. Pods Are Ephemeral#

This is another concept you must remember.

Pods are not permanent machines.

A Pod may be:

Created
   ↓
Running
   ↓
Deleted

And a replacement Pod may have:

• Different IP
• Different name
• Different node

For example:

api-abc123

dies.

Replacement:

api-xyz789

So applications shouldn't depend on a specific Pod identity.

25. What About Data?#

This raises an important question.

If Pods are ephemeral:

"Where should my database data go?"

Not directly inside the container's writable filesystem if you need it to survive Pod replacement.

Kubernetes provides persistent storage mechanisms such as:

PersistentVolume
PersistentVolumeClaim
StorageClass

We'll cover these later.

26. Pod Networking#

Every Pod generally gets its own IP.

Suppose:

Frontend Pod
10.244.0.10
 
Backend Pod
10.244.0.11

The Kubernetes networking model aims to allow Pods to communicate across nodes without requiring manual NAT between Pod addresses.

Conceptually:

Frontend Pod
     │
     │
     ↓
Kubernetes Network
     │
     ↓
Backend Pod

The exact implementation depends on the cluster's CNI/network plugin.

27. Pod Communication Across Nodes#

Imagine:

Node 1
└── Frontend Pod
    10.244.0.10
 
Node 2
└── Backend Pod
    10.244.1.20

Kubernetes networking allows the Pods to communicate across nodes.

Frontend
   │
   └──────── Kubernetes network ────────┐
                                        ↓
                                  Backend Pod

We'll go deep into this in the networking chapter.

28. Multi-Container Pod#

Let's look at a conceptual example:

apiVersion: v1
kind: Pod
 
metadata:
  name: app
 
spec:
  containers:
 
    - name: app
      image: my-app
 
    - name: sidecar
      image: log-agent

Now:

Pod
├── app container
└── sidecar container

Both share the Pod's network namespace.

29. Sidecar Pattern#

A sidecar is a helper container that runs alongside the main application.

Example:

Pod
├── Node.js Application
└── Log Collector

The application generates logs.

The sidecar processes or forwards them.

Another pattern:

Pod
├── Application
└── Proxy

The proxy might handle networking concerns.

Sidecars are useful, but don't put unrelated applications together just because Kubernetes allows multiple containers in a Pod.

30. Pod Storage Sharing#

Containers in the same Pod can also share a Kubernetes volume.

Conceptually:

Pod
├── App Container
│
├── Sidecar Container
│
└── Shared Volume

Both containers can mount the same volume.

Example:

App
 ↓
/shared/logs
 ↑
Sidecar

We'll study volumes separately.

31. Init Containers#

Another useful Pod concept is an Init Container.

An init container runs before the main application containers.

Example:

Pod
│
├── Init Container
│      ↓
│   Prepare environment
│
└── Application Container
       ↓
    Start application

For example, an init container might:

• Wait for a dependency
• Prepare files
• Perform initialization
• Set up data

Once the init container successfully finishes, the main container can start.

32. Pod Probes#

Kubernetes can check application health.

Three important probes:

Startup Probe
Readiness Probe
Liveness Probe

We'll study these in depth later.

Conceptually:

Application
     ↓
Health checks
     ↓
Kubernetes

For example:

Readiness = "Can I send traffic to you?"
Liveness  = "Are you still alive?"
Startup   = "Have you finished starting?"

33. Pod Resources#

A Pod's containers can have resource requirements.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

This tells Kubernetes about:

Request#

"I need approximately this much to be scheduled."

Limit#

"Don't allow this container to use beyond this configured limit for that resource."

This becomes very important for scheduling and autoscaling.

We'll cover it in detail later.

34. Real Example: Node.js API#

Suppose you have:

Node.js API

You create:

Docker Image

Then Kubernetes creates:

Pod
└── Node.js Container

If you want three instances:

Deployment
    ↓
ReplicaSet
    ↓
┌──────────┬──────────┬──────────┐
Pod 1      Pod 2      Pod 3
│          │          │
Node.js    Node.js    Node.js

Then a Service provides stable access:

                Service
                   ↓
          ┌────────┼────────┐
          ↓        ↓        ↓
        Pod 1    Pod 2    Pod 3

This is the architecture you'll build repeatedly.

35. Practical Exercise#

Let's create a Pod.

Step 1#

Create:

apiVersion: v1
kind: Pod
 
metadata:
  name: nginx
 
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Save it as:

nginx-pod.yaml

Step 2 — Apply#

kubectl apply -f nginx-pod.yaml

Step 3 — Check#

kubectl get pods

You should see:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          ...

Step 4 — Detailed information#

kubectl describe pod nginx

Look for:

Node:
IP:
Containers:
Image:
State:
Events:

Step 5 — Logs#

kubectl logs nginx

Nginx may not produce much output initially. That's okay.

Step 6 — Enter the container#

kubectl exec -it nginx -- /bin/bash

If /bin/bash isn't available in a particular image, use:

kubectl exec -it nginx -- /bin/sh

Then:

ls

Try:

cat /etc/os-release

Exit:

exit

36. Test Pod Failure#

This is a useful experiment.

Delete the Pod:

kubectl delete pod nginx

Then:

kubectl get pods

The Pod will be gone.

Why?

Because you created a standalone Pod.

There isn't a Deployment telling Kubernetes:

"I require one Pod to always exist."

This experiment demonstrates why production applications generally use Deployments.

37. Pod Mental Model#

Remember this:

                    POD
                     │
          ┌──────────┴──────────┐
          │                     │
      Container             Container
      (usually               (optional
       main app)              sidecar)
          │                     │
          └──────────┬──────────┘
                     │
              Shared Network
                     │
                  Pod IP

And:

Deployment
    ↓
ReplicaSet
    ↓
Pods
    ↓
Containers

🧠 Chapter 5 Cheat Sheet#

🎯 Interview Questions#

1. What is a Pod?#

A Pod is the smallest deployable unit in Kubernetes and contains one or more containers that share networking and can share storage.

2. Can a Pod have multiple containers?#

Yes.

Pod
├── App
└── Sidecar

3. Do containers in the same Pod have different IPs?#

Normally no. Containers in the same Pod share the Pod's network namespace and IP.

4. Can two Pods have the same IP?#

Not simultaneously within a normal Kubernetes cluster network.

5. Are Pod IPs permanent?#

No. Pods are ephemeral and replacement Pods can receive different IP addresses.

6. Why use a Deployment instead of directly creating Pods?#

A Deployment provides higher-level management such as maintaining replicas, rolling updates, and replacing failed Pods.

7. What is CrashLoopBackOff?#

It indicates a container is repeatedly failing and Kubernetes is repeatedly restarting it with increasing delays between attempts.

8. How do you investigate a crashing Pod?#

Start with:

kubectl get pods
kubectl logs <pod>
kubectl logs <pod> --previous
kubectl describe pod <pod>

🔥 The Most Important Concept#

Don't think:

"I have 3 containers."

Think:

"I have 3 Pods,
each containing my application container."

And in production:

Deployment
     ↓
  3 replicas
     ↓
┌────┬────┬────┐
Pod  Pod  Pod
 ↓    ↓    ↓
App  App  App

That mental model will make the next chapter much easier.

🚀 Next — Chapter 6: Deployments#

Now we'll learn the Kubernetes object you'll use far more often than standalone Pods:

Deployment
     ↓
ReplicaSet
     ↓
Pods

We'll cover:

• Why Deployments exist
• ReplicaSets
• replicas
• Desired vs current state
• Scaling
• Rolling updates
• Rollbacks
• Deployment YAML
• kubectl rollout
• What happens when you delete a Pod
• How Kubernetes replaces it automatically
• Deploying a real Node.js application
• Zero/minimal-downtime update concepts