You learned how to build an image.
You can start a container:
docker run myapp
You can inspect it, read its logs, attach volumes, configure networks, set resource limits, add health checks, and harden its security.
Then Docker Compose helps you run several services together.
So why does Kubernetes exist?
If Docker already does a good job of running containers, what problem is Kubernetes actually solving?
The answer becomes clearer when one container becomes hundreds.
1. Start With One Container
Imagine a simple web application.
User
│
▼
Web Container
│
▼
Database
Running it is straightforward:
docker run myapp
Nothing complicated yet.
Now traffic increases.
You need several application instances.
Then the application itself grows:
- Frontend
- API
- Database
- Redis
- Background workers
- Monitoring
- Logging components
Docker Compose can describe and run these services together:
docker compose up
For development and many single-host environments, that's extremely useful.
But then another requirement appears:
The application can no longer live on one machine.
2. When One Server Becomes Ten
Imagine you now have 100 containers that need to run across 10 machines.
Suddenly, docker run isn't the difficult part.
The difficult questions are:
Which machine should run each container?
What if that machine fails?
What if one container crashes?
What if traffic suddenly triples?
How do applications find containers that are constantly being replaced?
How do you update 50 instances without taking everything offline?
At this point, the problem has changed.
You're no longer dealing primarily with a container problem.
You're dealing with an orchestration problem.
3. This Is Where Kubernetes Enters
A useful simplified progression is:
This doesn't mean:
Docker = beginner
Kubernetes = advanced Docker
They're solving different layers of the problem.
Docker gives you tools to build and run containers.
Kubernetes gives you a system for coordinating containerized workloads across infrastructure.
And that changes the question you're asking.
4. Kubernetes Changes the Question
With Docker, you might say:
docker run myapp
You're directly telling the system what action to perform.
Kubernetes encourages a different model.
You describe the state you want.
For example:
I want three instances of this application running.
Conceptually:
replicas: 3
Kubernetes continually works to make reality match that desired state.
Desired State
│
▼
3 replicas should exist
│
▼
Kubernetes observes reality
│
▼
Only 2 exist?
│
▼
Create another
That idea — desired state and reconciliation — is one of the biggest mental shifts from manually operating containers.
You stop thinking only about:
"Start this container."
And start thinking:
"Keep my application in this state."
5. What Happens When Things Fail?
Suppose your application should have three instances:
App 1 App 2 App 3
✓ ✓ ✓
Then one fails:
App 1 App 2 App 3
✓ ✗ ✓
You don't want someone to discover the failure and manually create a replacement.
Kubernetes controllers continuously compare the current state with the desired state.
If three replicas should exist but only two remain, Kubernetes can work to restore the desired number.
Desired: 3
Actual: 2
↓
Create replacement
↓
Actual: 3
But containers aren't the only things that fail.
Machines fail too.
Imagine:
Node 1
├─ App
└─ Worker
Node 2
├─ App
└─ API
Node 3
├─ App
└─ Worker
If Node 2 becomes unavailable, several workloads may disappear at once.
Now another question appears:
Where should the replacements run?
Kubernetes can schedule replacement workloads onto available nodes according to the workload configuration and cluster conditions.
Failure has moved from being something you manually react to into something the platform continuously observes and responds to.
That's a major reason orchestration exists.
6. From Containers to Scheduled Pods
Kubernetes doesn't normally manage an individual container as its smallest deployable unit.
It manages a Pod.
Conceptually:
Pod
│
├── Application Container
│
└── Optional Supporting Container
A Pod can contain one or more tightly coupled containers that share certain resources such as networking.
Most commonly, you'll still encounter one main application container per Pod.
Containers haven't disappeared.
Kubernetes has added a management layer around them.
But now we have another problem.
Suppose the cluster contains several nodes with different available resources.
Where should a new Pod run?
Doing this manually for hundreds of workloads would quickly become difficult.
Kubernetes uses its scheduler to select an appropriate node based on factors such as:
- Resource requirements
- Scheduling constraints
- Node conditions
- Affinity rules
- Taints and tolerations
The important change is this:
Placement becomes a cluster decision instead of a human manually choosing a server.
7. Scaling Creates Another Problem
Suppose three application instances normally handle your traffic.
Then traffic increases dramatically.
You need six.
Docker can certainly start more containers.
But in a larger environment, you also need a system that understands:
- How many instances should exist
- Where they should run
- Whether enough resources are available
- What should happen when instances fail
Kubernetes workloads can be scaled manually, and Kubernetes also supports automatic scaling based on configured metrics and policies.
But creating more instances introduces another problem.
How does anything reliably find them?
8. Replaceable Pods Need Stable Networking
Pods are designed to be replaceable.
Suppose an API Pod has this IP:
10.0.1.7
It disappears.
A replacement appears with a different IP:
10.0.3.12
If your frontend depends directly on the old address, it now points at something that no longer exists.
Kubernetes solves this problem with Services.
Frontend
│
▼
API Service
│
┌─────┼─────┐
▼ ▼ ▼
Pod A Pod B Pod C
Pods can come and go.
The Service provides a stable way to reach the workload.
That reveals another important Kubernetes idea:
The individual instance is temporary. The application identity should remain stable.
9. Docker Concepts Don't Disappear
This is where learning Docker first starts paying off.
Many of the problems you've already encountered still exist in Kubernetes.
| Docker concept | Kubernetes world |
|---|---|
| Container | Container inside a Pod |
| Image | Container image |
| Resource limits | Requests and limits |
| Health checks | Liveness, readiness, and startup probes |
| Networking | Pod and Service networking |
| Persistent data | Persistent Volumes / Claims |
| Environment/config | ConfigMaps and Secrets |
| Restart/recovery thinking | Controllers and reconciliation |
Kubernetes doesn't make Docker knowledge useless.
It builds on many of the same container fundamentals while adding orchestration around them.
Take health checks as an example.
With Docker, we learned:
Running doesn't necessarily mean healthy.
Kubernetes makes the distinction even more useful.
Liveness Probe
Roughly asks:
Is this container functioning, or should Kubernetes restart it?
Readiness Probe
Asks:
Is this Pod currently ready to receive traffic?
Startup Probe
Helps protect slow-starting applications from liveness checks being applied too early.
An application can therefore be alive without being ready to serve users.
Alive ≠ Ready
The underlying problem hasn't disappeared.
The orchestration layer simply has more ways to respond to it.
10. Updating One Container Is Easy. Updating Fifty Isn't.
Replacing one Docker container is straightforward.
But imagine updating 50 application instances.
Stopping all of them at once could create downtime.
Instead, you'd prefer something like:
Old Old Old Old
↓
New Old Old Old
↓
New New Old Old
↓
New New New Old
↓
New New New New
Kubernetes Deployments support controlled rolling updates.
If something goes wrong, rollout history and rollback mechanisms can help return the workload to an earlier revision.
Again, Kubernetes isn't making the individual container smarter.
It's coordinating how a group of containerized instances changes over time.
That's the pattern throughout this article.
The container isn't necessarily the difficult part anymore.
Coordinating all the containers is.
11. Kubernetes Didn't Simply Replace Docker
This is one of the most common misconceptions.
You may have heard:
"Kubernetes stopped using Docker."
That can make it sound as though Docker images somehow stopped working with Kubernetes.
They didn't.
Kubernetes needs a container runtime to actually run containers.
Modern Kubernetes communicates with container runtimes through the Container Runtime Interface (CRI).
Common examples include:
containerdCRI-O
Kubernetes removed its old Docker-specific integration layer, known as dockershim.
But that doesn't mean Docker-built container images became unusable.
The important takeaway is:
Docker images didn't stop working with Kubernetes. Kubernetes changed how it communicates with container runtimes.
A simplified model is:
Build Container Image
│
▼
Store in Registry
│
▼
Kubernetes
│
▼
Container Runtime
│
▼
Run Containers
So the choice isn't simply:
Docker OR Kubernetes.
Different tools are operating at different layers.
12. So When Does Docker Stop Being Enough?
Not every application needs Kubernetes.
That's important.
If you have:
- A few containers
- One server
- Predictable traffic
- Simple deployments
- Limited scaling requirements
Docker or Docker Compose may be completely sufficient.
Adding Kubernetes could simply introduce complexity you don't need.
Kubernetes starts becoming more useful when the problems themselves change:
- Many workloads
- Multiple machines
- Automated scheduling
- Failure recovery
- Service discovery
- Horizontal scaling
- Rolling deployments
- High availability
- Cluster-wide resource management
So perhaps the wrong question is:
"When should I graduate from Docker to Kubernetes?"
A better question is:
"Do I actually have an orchestration problem?"
If the answer is no, Kubernetes may be solving a problem you don't have.
The Journey From docker run
This series started with a deceptively simple command:
docker run
Then we went underneath it.
We explored:
- Docker internals
- Image builds
- Networking
- Storage
- Container security
- Docker Compose
- Production reliability
- Rootless Docker and advanced security
And something interesting happened.
The deeper we went, the less Docker looked like simply:
"A tool that runs containers."
We started seeing the Linux kernel.
Namespaces.
cgroups.
Filesystems.
Networks.
Security boundaries.
Resource management.
Application lifecycle.
Eventually, the question changed.
It was no longer:
How do I run this container?
It became:
How do I reliably operate large numbers of containers across multiple machines?
That's where the container problem becomes an orchestration problem.
And that's where Kubernetes begins.
Docker is surprisingly easy to start with.
That's one of its greatest strengths.
But underneath that simple experience is a much deeper system.
You don't need to master every Docker internal before learning Kubernetes.
But understanding the foundation makes Kubernetes feel much less mysterious.
Because eventually you realize:
Kubernetes isn't where containers begin.
It's what becomes useful when operating containers becomes the bigger problem.
Question for You
When did Kubernetes start making sense to you — while learning Pods and Deployments, or only after understanding the problems orchestration is trying to solve?
Top comments (0)