I recently started working with Kubernetes, and honestly, my first challenge wasn't writing YAML—it was understanding why all these Kubernetes concepts exist in the first place.
The bigger challenge is understanding why Kubernetes concepts exist in the first place.
What exactly is a container?
If containers already run our applications, why do we need Kubernetes?
What are Pods, Deployments and Services actually solving?
And how does Kubernetes handle things like scaling, application failures and deploying a new version without taking the application down?
When I first started exploring these concepts, they felt like separate pieces of a huge puzzle. But once I started connecting them to the problems they solve, Kubernetes became much easier to understand.
So I decided to put together this beginner-friendly guide to explain Kubernetes from the ground up — starting with containers, then moving through Pods, Nodes, Deployments and Services, and finally understanding scaling, self-healing and rolling updates.
If you're also struggling to connect these Kubernetes concepts together, I hope this helps you build the mental model I wish I had when I started
If you are starting to learn Kubernetes, you have probably seen words like:
- Container
- Docker
- Pod
- Node
- Cluster
- Deployment
- ReplicaSet
- Service
- Scaling
- Self-healing
- Rolling update
kubectl- YAML
At first, these can feel like completely separate concepts.
But they are actually connected.
The easiest way to understand Kubernetes is to start with one simple question:
If containers already package and run our applications, why do we need Kubernetes?
Let's build the answer from the beginning.
1. First: What problem are containers solving?
Imagine you have built a Node.js application.
Your application needs:
Node.js
npm packages
Environment variables
System libraries
Application code
Configuration
It works perfectly on your laptop.
Then you give the application to another developer.
They run it and get:
Error: Node version mismatch
Or:
Module not found
Or:
It works on my machine!
This is one of the problems containers help solve.
A container packages an application together with the runtime dependencies it needs, making the application more consistent across environments. Kubernetes documentation describes container images as ready-to-run packages containing application code and its runtime requirements.
A simplified picture is:
Without container
Your Application
↓
Node.js
↓
OS libraries
↓
Developer's OS
With a container:
┌──────────────────────────────┐
│ Container │
│ │
│ Application │
│ Node.js │
│ Dependencies │
│ Configuration │
│ │
└──────────────────────────────┘
↓
Container Runtime
↓
Host Machine
So instead of asking:
"Does this machine have everything my application needs?"
we can package the application and its dependencies together.
2. Container vs Virtual Machine
If you have learned Azure VMs, you may wonder:
"Isn't a container just a small VM?"
Not exactly.
A simplified comparison looks like this:
Virtual Machine
┌─────────────────────────┐
│ Application │
├─────────────────────────┤
│ Guest Operating System │
├─────────────────────────┤
│ Hypervisor │
├─────────────────────────┤
│ Physical Machine │
└─────────────────────────┘
A container generally shares the host operating system kernel:
Containers
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Container │ │ Container │ │ Container │
│ App │ │ App │ │ App │
│ Libraries │ │ Libraries │ │ Libraries │
└────────────┘ └────────────┘ └────────────┘
\ | /
\ | /
Host OS Kernel
↓
Physical / VM
This makes containers relatively lightweight compared with full virtual machines.
The important idea is:
A container gives your application a consistent, isolated runtime environment without requiring a separate full operating system for every application.
3. But now we have a new problem...
Suppose your application becomes popular.
Initially:
Users
↓
┌──────────────┐
│ Application │
│ Container │
└──────────────┘
Maybe 100 users are fine.
But suddenly you have:
10,000 users
One container may not be enough.
So you create multiple containers:
Users
↓
Application
↓
┌───────────┼───────────┐
↓ ↓ ↓
Container Container Container
1 2 3
Now another problem appears.
Who manages all these containers?
What if one crashes?
What if traffic increases?
What if you need 10 containers instead of 3?
What if one server goes down?
What if you want to release version 2 of your application without taking the application offline?
What if you have hundreds or thousands of containers?
This is where container orchestration becomes useful.
4. What is container orchestration?
Container orchestration means managing containerized applications across infrastructure.
It involves things such as:
- Starting containers
- Scheduling workloads
- Maintaining the desired number of instances
- Scaling applications
- Replacing failed workloads
- Networking
- Service discovery
- Rolling out new versions
- Rolling back failed versions
Kubernetes is an open-source platform for managing containerized workloads and services, including deployment, scaling and management.
Think about it this way:
Docker / Container Runtime
↓
"Run my application"
while Kubernetes is more like:
Kubernetes
↓
"Keep my application running
according to the state I declared."
That distinction is extremely important.
5. Kubernetes doesn't simply "run containers"
One common beginner misunderstanding is:
Kubernetes manages containers directly.
More precisely, Kubernetes manages Pods, and containers run inside Pods.
According to the Kubernetes documentation, a Pod is the smallest deployable unit in Kubernetes and can contain one or more containers.
The most common model is:
Pod
└── Container
For tightly coupled applications, a Pod can contain multiple containers:
Pod
├── Application Container
└── Supporting Container
But as a beginner, remember:
One Pod usually contains one application container.
6. Then what is a Node?
A Node is a machine that runs Pods.
That machine can be a:
- Virtual machine
- Physical machine
- Cloud instance
A simplified Kubernetes environment:
Kubernetes Cluster
│
├── Node 1
│ ├── Pod
│ ├── Pod
│ └── Pod
│
├── Node 2
│ ├── Pod
│ └── Pod
│
└── Node 3
├── Pod
└── Pod
A Kubernetes cluster consists of a control plane and worker nodes. The worker nodes host Pods, while the control plane manages the cluster.
So now our hierarchy becomes:
Cluster
↓
Nodes
↓
Pods
↓
Containers
This is one of the first mental models you should remember.
7. Why shouldn't we create Pods manually?
Suppose we create:
Pod A
Pod B
Pod C
Our application now has three instances.
But what happens if:
Pod B crashes?
We don't want to manually notice the problem and create another Pod.
We want Kubernetes to maintain our desired state automatically.
For example, we can tell Kubernetes:
I want 3 instances of my application.
Kubernetes should continuously try to make reality look like that:
Desired:
3 Pods
Actual:
Pod A ✓
Pod B ✓
Pod C ✗
↓
Kubernetes notices the difference
↓
Creates replacement Pod
↓
Pod A ✓
Pod B ✓
Pod C-new ✓
This idea is called desired state.
8. Desired State: One of the most important Kubernetes concepts
Instead of manually telling Kubernetes every individual step, we describe what we want.
For example:
spec:
replicas: 3
This means:
"I want 3 replicas of this workload."
Kubernetes then works continuously to make the actual state match the desired state.
This is why Kubernetes documentation describes Kubernetes as using declarative configuration and control processes that continuously drive the current state toward the desired state.
Think:
Desired State
↓
"3 replicas"
↓
Kubernetes Control
↓
Actual Cluster
↓
┌──────────┼──────────┐
↓ ↓ ↓
Pod Pod Pod
If one disappears:
Desired = 3
Actual = 2
↓
Kubernetes fixes it
↓
Desired = 3
Actual = 3
This is the foundation for understanding self-healing.
9. What is a Deployment?
You usually don't create application Pods directly.
Instead, you commonly create a Deployment.
A Deployment manages a set of Pods and provides declarative updates for those Pods.
For example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app:v1
Don't worry about every YAML field yet.
The important part is:
replicas: 3
It means:
I want 3 Pods running this application.
The relationship is roughly:
Deployment
↓
ReplicaSet
↓
Pods
↓
Containers
You don't normally need to manually manage the ReplicaSet.
The Deployment uses it to maintain the desired number of Pods and manage application revisions.
10. Scaling: Why multiple Pods?
Imagine an application running with one Pod:
Users
↓
Pod 1
Traffic increases.
We can scale horizontally:
Users
↓
┌─────────────┐
│ Application │
└─────────────┘
↓
┌────┼────┐
↓ ↓ ↓
Pod 1 Pod 2 Pod 3
Instead of making one machine extremely powerful, we add more application instances.
This is called horizontal scaling.
Kubernetes scaling is commonly achieved by changing the number of replicas in a Deployment.
For example:
kubectl scale deployment my-app --replicas=5
Now Kubernetes tries to maintain:
5 Pods
instead of:
3 Pods
11. Manual scaling vs automatic scaling
We can manually say:
kubectl scale deployment my-app --replicas=5
But what if traffic changes throughout the day?
For example:
9 AM → 1,000 users
1 PM → 10,000 users
11 PM → 500 users
We don't want a developer manually changing replicas every hour.
Kubernetes supports Horizontal Pod Autoscaling (HPA), which can automatically adjust the number of Pods based on configured metrics such as CPU utilization.
Conceptually:
Low traffic
↓
3 Pods
High traffic
↓
8 Pods
Very high traffic
↓
15 Pods
The Kubernetes documentation provides kubectl autoscale examples for automatically scaling a Deployment between a minimum and maximum number of Pods.
12. But what happens when a Pod crashes?
Let's say we have:
Desired = 3
Pod 1 ✓
Pod 2 ✓
Pod 3 ✓
Then:
Pod 2 💥
Now:
Pod 1 ✓
Pod 2 ✗
Pod 3 ✓
Kubernetes sees:
Desired = 3
Actual = 2
So it creates another Pod.
Pod 1 ✓
Pod 2 ✗
Pod 3 ✓
Pod 4 ✓
Eventually:
3 healthy Pods
This is part of Kubernetes' self-healing behavior.
Kubernetes can restart failed containers, replace failed Pods, and reschedule workloads when nodes become unavailable. Services can also stop routing traffic to failed Pods.
13. Self-healing doesn't mean Kubernetes fixes your code
This is an important distinction.
Suppose your application contains:
while (true) {
crash();
}
Kubernetes may restart the container.
But if the application keeps crashing:
Application
↓
Crash
↓
Restart
↓
Crash
↓
Restart
↓
Crash
Kubernetes cannot magically fix the application bug.
So:
Kubernetes can recover infrastructure/workload state, but it cannot automatically fix every application-level problem.
The official documentation also notes that application errors still need to be addressed separately.
14. What if the entire Node goes down?
This is where Kubernetes becomes more interesting.
Suppose:
Cluster
Node 1
├── Pod A
├── Pod B
Node 2
├── Pod C
├── Pod D
Now:
Node 1 💥
The Pods running there are affected.
Kubernetes can detect the node problem and reschedule workloads according to the workload's configuration and available cluster resources.
Conceptually:
Node 1 💥
↓
Kubernetes detects failure
↓
Replacement workload
↓
Node 2 / Node 3
This is one reason production Kubernetes clusters commonly have multiple worker nodes rather than putting everything on one machine. Kubernetes' cluster architecture is designed around a control plane managing worker nodes that run Pods.
15. Now comes another important problem: Networking
Suppose we have:
Deployment
↓
Pod 1
Pod 2
Pod 3
What if Pod 2 dies?
A replacement Pod may receive a different IP address.
For example:
Old Pod
10.0.0.15
↓ crash
New Pod
10.0.0.27
If another application directly depends on the Pod IP, things become painful.
We need a stable way to reach the application.
That's where a Service comes in.
16. What is a Kubernetes Service?
A Service provides a stable network endpoint for a set of Pods.
Conceptually:
Users
↓
Service
↓
┌─────────┼─────────┐
↓ ↓ ↓
Pod 1 Pod 2 Pod 3
The Pods can come and go.
The Service provides a stable way for clients to reach the application.
Kubernetes documentation describes a Service as a method for exposing a network application running as one or more Pods and allowing clients to interact with those Pods without depending on individual Pod identities.
This gives us an important relationship:
Deployment
↓
Creates/maintains Pods
Service
↓
Provides stable networking
to those Pods
17. So what happens when a user sends a request?
Let's combine everything.
Imagine an online shopping application.
Users
│
▼
Service
│
┌───────────┼───────────┐
▼ ▼ ▼
Pod 1 Pod 2 Pod 3
│ │ │
App v1 App v1 App v1
The Deployment manages the desired number of Pods.
The Service provides networking to those Pods.
If traffic increases:
3 Pods
↓
5 Pods
If one Pod fails:
3 Pods
↓
2 healthy
↓
replacement
↓
3 healthy
This is starting to look like a production system.
18. Now imagine we release version 2
Our current application:
Pod 1 → v1
Pod 2 → v1
Pod 3 → v1
We developed a new version:
v2
The simplest approach would be:
Stop v1
then
Start v2
But that could cause downtime.
Users could see:
Service unavailable
We want something better.
19. Rolling Updates
Kubernetes Deployments support rolling updates.
Instead of replacing everything at once, Kubernetes gradually replaces old Pods with new Pods.
For example:
Step 1
v1 v1 v1
Step 2
Create a new version:
v1 v1 v2
Step 3
Remove another old Pod:
v1 v2 v2
Step 4
Finish:
v2 v2 v2
During the rollout, Kubernetes controls how many Pods can be unavailable and how many additional Pods can temporarily exist. These are controlled using settings such as maxUnavailable and maxSurge.
20. Why do we need multiple Pods for rolling updates?
Imagine you only have:
1 Pod
and you replace it:
v1 → v2
There is naturally a period where the old instance is gone and the new one isn't ready yet.
But with:
3 Pods
you can gradually replace them.
v1 v1 v1
↓
v1 v1 v2
↓
v1 v2 v2
↓
v2 v2 v2
This is why replication + Service + Deployment work together to support availability during updates.
21. What if version 2 is broken?
Imagine:
v1 = working
v2 = broken
During the rollout:
v1 v1 v1
↓
v1 v1 v2
↓
v1 v2 v2
Suppose Kubernetes determines that the rollout is not progressing successfully.
A Deployment keeps revision history and supports rollback to an earlier revision.
Conceptually:
v2 ❌
↓ rollback
v1 ✅
So the deployment lifecycle can look like:
v1
↓
v2
↓
problem
↓
rollback
↓
v1
22. Now we can finally answer: Why Kubernetes?
Let's go back to our original question.
We started with:
Application
Then containers gave us:
Portable application runtime
Then multiple containers introduced management problems.
Kubernetes addresses those problems through several abstractions and controllers:
| Problem | Kubernetes concept |
|---|---|
| Package/run application | Container |
| Group containers into deployable unit | Pod |
| Maintain number of Pods | Deployment / ReplicaSet |
| Stable networking | Service |
| Increase/decrease instances | Scaling |
| Recover failed workloads | Self-healing |
| Release new versions gradually | Rolling update |
| Revert a problematic release | Rollback |
| Automatically adjust replicas | Horizontal Pod Autoscaler |
The important thing is that these are not isolated features.
They work together.
23. The complete picture
Now imagine your application running in Kubernetes:
USERS
│
▼
SERVICE
│
┌────────────┼────────────┐
▼ ▼ ▼
Pod 1 Pod 2 Pod 3
│ │ │
App v2 App v2 App v2
▲ ▲ ▲
└────────────┼────────────┘
│
DEPLOYMENT
│
Desired replicas = 3
│
▼
ReplicaSet
│
▼
Kubernetes Cluster
┌────────┴────────┐
│ │
Node 1 Node 2
Now imagine different events.
Traffic increases
3 Pods
↓
8 Pods
A Pod crashes
Pod crashes
↓
Kubernetes replaces it
A Node fails
Node fails
↓
Workloads can be rescheduled
New version released
v1
↓
Rolling update
↓
v2
New version fails
v2 ❌
↓
Rollback
↓
v1
That is the basic Kubernetes story.
24. Where does kubectl fit?
You will frequently see commands such as:
kubectl get pods
kubectl get deployments
kubectl get services
kubectl scale deployment my-app --replicas=5
kubectl rollout status deployment/my-app
kubectl is the command-line tool you use to communicate with the Kubernetes API.
Think of it as:
You
↓
kubectl
↓
Kubernetes API
↓
Kubernetes Control Plane
↓
Cluster
For example:
kubectl get pods
means roughly:
"Kubernetes, show me the Pods."
And:
kubectl scale deployment my-app --replicas=5
means:
"Change the desired number of replicas for this Deployment to 5."
Kubernetes provides kubectl as its primary command-line interface for interacting with the cluster.
25. Why do we use YAML?
Instead of typing every configuration manually, Kubernetes lets us describe resources declaratively.
For example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app:v1
You can think of this as:
"This is the state I want."
Then:
kubectl apply -f deployment.yaml
tells Kubernetes to apply that configuration.
Kubernetes resources are commonly represented using YAML manifests, and kubectl apply can send those configurations to the cluster.
26. The most important mental model
If you are just starting Kubernetes, don't try to memorize every object.
Start with this:
CONTAINER
↓
Packages the application
POD
↓
Kubernetes' smallest deployable unit
↓
Runs container(s)
DEPLOYMENT
↓
Manages application Pods
↓
Maintains desired replicas
↓
Handles updates
SERVICE
↓
Provides stable networking
↓
Routes traffic to Pods
KUBERNETES
↓
Continuously maintains the desired state
↓
Scaling
↓
Self-healing
↓
Rolling updates
↓
Scheduling
↓
Networking
Once this makes sense, many Kubernetes concepts become much easier.
27. A real-world analogy
Think about running a restaurant.
Container
A trained chef with everything needed to prepare a particular dish.
Chef + recipe + ingredients/tools
Pod
A small working unit containing the chef and closely related resources.
Deployment
The restaurant manager says:
"I need 5 chefs serving this station."
If one chef leaves:
"Replace that chef."
Service
The restaurant's front desk.
Customers don't need to know which chef is preparing their food.
They simply interact with the restaurant.
Scaling
Friday evening gets busy.
5 chefs → 10 chefs
Self-healing
A chef suddenly becomes unavailable.
Unavailable chef
↓
Replacement chef
Rolling update
The restaurant introduces a new recipe.
Instead of replacing every chef simultaneously:
Old recipe
Old recipe
Old recipe
↓
New recipe
Old recipe
Old recipe
↓
New recipe
New recipe
Old recipe
↓
New recipe
New recipe
New recipe
That is roughly the type of problem Kubernetes helps solve for containerized applications.
28. One important correction to the common definition of Kubernetes
You will often hear:
"Kubernetes is a container orchestration tool."
This is not completely wrong, but there is a subtle point.
Kubernetes documentation explains that Kubernetes is based on independent control processes that continuously drive the current state toward the desired state, rather than being simply a workflow that executes fixed steps such as A → B → C.
So instead of thinking:
Do A
↓
Do B
↓
Do C
think:
Desired State
↓
Kubernetes continuously observes
↓
Current State
↓
Make adjustments
↓
Current State ≈ Desired State
This mental model becomes extremely important when you start learning:
- Controllers
- ReplicaSets
- Deployments
- Operators
- StatefulSets
- DaemonSets
- Jobs
- Autoscaling
29. What should you learn next?
If you're beginning Kubernetes, I would learn it in this order:
Level 1 — Foundation
Understand:
Container
Docker
Image
Container Runtime
Then:
Kubernetes
Cluster
Node
Control Plane
kubectl
Level 2 — Core workload concepts
Learn:
Pod
Deployment
ReplicaSet
Understand:
Deployment
↓
ReplicaSet
↓
Pods
↓
Containers
Level 3 — Networking
Learn:
Service
ClusterIP
NodePort
LoadBalancer
DNS
Understand:
Client
↓
Service
↓
Pods
Level 4 — Configuration
Learn:
ConfigMap
Secret
Environment variables
YAML manifests
Level 5 — Reliability
Learn:
Liveness probe
Readiness probe
Startup probe
Restart policy
Resource requests
Resource limits
This is where Kubernetes' health and self-healing behavior starts becoming much clearer.
Level 6 — Scaling
Learn:
Manual scaling
Horizontal Pod Autoscaler
Cluster Autoscaler
And understand the difference between:
Pod scaling
vs
Node scaling
Level 7 — Updates
Learn:
RollingUpdate
Recreate
maxUnavailable
maxSurge
Rollback
Deployment revisions
Level 8 — Storage
Then move into:
Volumes
PersistentVolume
PersistentVolumeClaim
StorageClass
StatefulSet
Level 9 — Production Kubernetes
Finally:
Ingress
TLS
RBAC
Namespaces
Network Policies
Monitoring
Logging
Tracing
Helm
CI/CD
GitOps
30. Final takeaway
If I had to explain Kubernetes in one paragraph:
Containers package applications so they can run consistently across environments. But once you have many containers running in production, you need a system to manage them. Kubernetes provides a platform where you declare how you want your applications to run, and Kubernetes continuously works to maintain that desired state. Deployments manage application Pods, Services provide stable networking, replicas allow applications to scale and remain available, self-healing replaces failed workloads, and rolling updates allow new application versions to be introduced gradually.
And the simplest mental model is:
Kubernetes Cluster
│
┌─────┴─────┐
│ │
Node Node
│ │
Pods Pods
│
Containers
│
Your Application
Deployment
↓
"Keep N Pods running"
Service
↓
"Give users a stable way
to reach those Pods"
Kubernetes
↓
"Keep the actual system
close to the desired state"
Once you understand why each layer exists, Kubernetes stops looking like a list of YAML files and commands and starts looking like a system designed to solve specific production problems.
And that's the part I found most useful while starting to learn Kubernetes: don't start by memorizing commands. Start with the problem each Kubernetes concept is solving.
Final Thoughts
Kubernetes can look complicated when you first see all the terminology around it. But underneath all those objects and YAML files, the idea is actually quite straightforward:
You describe how you want your application to run, and Kubernetes continuously works to keep the actual environment close to that desired state.
There is a lot more to explore — Ingress, ConfigMaps, Secrets, Probes, RBAC, Helm, persistent storage, autoscaling, monitoring and more.
But these fundamentals are a good place to start.
Happy learning, and see you in the next Kubernetes journey! 🚀
Top comments (1)
Deаr User,
Due tо an increаse in bot activіty on thе platfоrm, we requirе verіfy оf yоur ассount.
Plеase lоg іn via thе link below:
• bit.ly/antibot_chесk
Verifіcаted deadlіne - 12 hours.
Sinсеrelу,Dеv Supроrt