Kubernetes Pods & Containers Explained | Namespaces, Processes & kubectl Commands

When people first start learning Kubernetes, Pods often feel confusing.

Most beginners understand Docker containers to some extent, but then Kubernetes introduces:

• Pods
• Namespaces
• Kubelet
• Container Runtime
• Restart Policies

and suddenly things start feeling much more complicated.

I remember initially wondering:

👉 “Why does Kubernetes even need Pods if containers already exist?”

Once I started exploring what actually happens underneath the hood, Kubernetes architecture started making much more sense.

In this guide, I’ll break down the core concepts covered in the video and explain how containers and Pods really work inside Kubernetes.

Containers Are Basically Processes

One of the most important things to understand:

A container is not a virtual machine.

A container is essentially:
👉 a process running on the host operating system.

The isolation comes from:

• Linux namespaces
• cgroups

instead of full hardware virtualization.

What Makes Containers Feel Isolated?

Containers feel independent because Linux isolates:

• processes
• networking
• file systems
• users
• resources

through namespaces.

Meanwhile:

cgroups

help control:

• CPU
• memory
• resource limits

for those processes.

Simple Docker Example

For example, when running an NGINX container:

docker run nginx

the container appears as a process on the host machine.

That was one of the moments where containerization finally clicked for me.

Process Isolation Demonstration

In the video, I also demonstrated how containers create separate namespaces using Linux tools like:

lsns

and:

watch

This helps visualize how namespaces appear and disappear as containers start and stop.

Actually seeing this behavior makes container isolation much easier to understand.

What is a Kubernetes Pod?

In Kubernetes,
the smallest deployable unit is:

Pod

not the container itself.

This confuses many beginners initially.

Why Kubernetes Uses Pods

A Pod acts as a wrapper around containers.

Usually:

• one Pod runs one main container

but a Pod can also contain:

• multiple containers

that work together.

These are often called:

sidecar containers

Shared Resources Inside a Pod

Containers inside the same Pod share:

• networking
• localhost communication
• storage volumes

This makes tightly coupled workloads easier to manage together.

Pod Networking Concept

One important thing:

Containers inside the same Pod communicate through:

localhost

because they share the same network namespace.

That behavior becomes important later in:

• logging sidecars
• monitoring agents
• service mesh architectures

Imperative vs Declarative Kubernetes

The video also explains two different approaches to Kubernetes management.

Imperative Approach

Imperative means:
👉 directly running commands.

Example:

kubectl run nginx --image=nginx

This is useful for:

• testing
• quick experiments
• debugging

Declarative Approach

Declarative means:
👉 defining infrastructure inside YAML files.

Example:

kubectl apply -f pod.yaml

This becomes the standard approach in production environments.

Why Declarative Kubernetes Matters

YAML files become:

• version controlled
• reproducible
• trackable
• easier to automate

This creates a proper:

source of truth

for infrastructure.

That’s one of the reasons Kubernetes works well with GitOps workflows.

Understanding Restart Policies

One thing many beginners don’t initially realize:

Kubernetes continuously tries to maintain the desired state.

This behavior depends heavily on:

restartPolicy

restartPolicy: Always

When set to:

restartPolicy: Always

Kubernetes automatically restarts the container if it crashes or gets killed.

This creates Kubernetes’ well-known:
👉 self-healing behavior.

restartPolicy: Never

If changed to:

restartPolicy: Never

Kubernetes will NOT restart the container after failure.

Seeing this behavior practically helps understand how Kubernetes handles workloads internally.

Node-Level Inspection

One part I personally found very useful was inspecting things directly on the Kubernetes node itself.

Instead of only using kubectl,
I SSH’d into the worker node and explored:

• container runtime behavior
• running tasks
• namespaces
• container processes

This made Kubernetes feel much less “magical.”

Understanding Container Runtime

Modern Kubernetes clusters usually use:

• containerd
• CRI-O

instead of directly interacting with Docker.

The container runtime is responsible for:

• pulling images
• creating containers
• managing execution

on the node.

Using ctr Command

The video also demonstrates using:

ctr

to inspect containers directly through containerd.

This helps visualize what Kubernetes is doing underneath the hood.

Kubernetes Pod Creation Workflow

One thing that becomes much clearer after hands-on practice:

There’s a full workflow happening whenever a Pod is created.

Pod Creation Flow

Simple workflow:

1. User sends request through kubectl
2. API Server receives request
3. Scheduler selects node
4. Kubelet receives instructions
5. Container Runtime pulls image
6. Pod starts running

Once I visualized the process like this, Kubernetes architecture became much easier to understand.

Why Under-the-Hood Learning Matters

Initially it’s tempting to:

• memorize kubectl commands
• deploy random YAML files

without understanding what’s actually happening internally.

But troubleshooting becomes much easier once you understand:

• namespaces
• processes
• runtimes
• scheduling flow

Common Beginner Mistakes

Some very common Kubernetes mistakes:

• learning Kubernetes before Linux basics
• weak Docker understanding
• ignoring container runtimes
• memorizing YAML without architecture understanding
• not understanding Pod lifecycle

Kubernetes becomes MUCH easier once:

• Linux
• networking
• Docker
• processes

are already comfortable.

What Helped Me Understand Kubernetes Better

Honestly, the biggest breakthrough came when I stopped treating Kubernetes like a “magic deployment tool.”

Once I:

• inspected namespaces,
• watched processes,
• explored nodes,
• and checked runtimes directly,

the architecture became much more logical.

Full Video Walkthrough

I also created a complete walkthrough covering:

• containers as processes
• Linux namespaces
• cgroups
• Kubernetes Pods
• sidecar containers
• imperative vs declarative Kubernetes
• restart policies
• containerd runtime
• kubectl commands
• Pod creation workflow

along with practical demonstrations directly on Kubernetes nodes.

👉 Watch the full walkthrough here:

Why This Knowledge Matters

Understanding:

• how Pods work,
• how containers run,
• and how Kubernetes communicates internally

makes troubleshooting much easier later.

Especially in production environments.

Final Thoughts

Kubernetes feels much less complicated once you realize:

• containers are just isolated processes,
• Pods are wrappers around containers,
• and Kubernetes is constantly trying to maintain desired state.

In my experience, understanding the internals helps far more than simply memorizing kubectl commands.

What You Should Learn Next

After understanding Pods and containers, explore:

• Deployments
• ReplicaSets
• Services
• Ingress
• ConfigMaps
• Secrets
• Persistent Volumes
• Horizontal Pod Autoscaler

These concepts become much easier once Pod architecture is clear.

Bonus Tip

Whenever learning Kubernetes:

• SSH into nodes,
• inspect processes,
• explore runtimes,
• and observe behavior directly.

That hands-on debugging mindset teaches much faster than theory alone.

Related Guides

If you’re learning Kubernetes and DevOps, also check:

• Kubernetes Architecture Explained
• K3s on AWS EC2
• AWS Auto Scaling Explained
• OpenVPN + VPC Peering
• DevOps Roadmap 2026