“Before Kubernetes can heal your application, it must first understand what your application should look like.”
Introduction
In the previous article, we discussed why failures are inevitable in distributed systems and why modern applications must be designed to recover automatically.
But this raises an important question.
How does Kubernetes know that something has failed?
If a pod crashes…
- Who detects it?
- Who creates a new pod?
- How does traffic get redirected?
- Who decides where the new pod should run?
- How does Kubernetes know the desired number of replicas?
Many developers think Kubernetes is a single application.
It isn’t.
Kubernetes is a collection of specialized components continuously working together to maintain the desired state of your application.
Understanding these components is one of the most valuable investments any Java developer can make.
Once you understand how Kubernetes thinks, many production issues suddenly become much easier to diagnose.
What is Kubernetes?
Kubernetes (often abbreviated as K8s) is an orchestration platform for managing containerized applications.
Notice what it doesn’t do.
Kubernetes is not:
- an application server
- a container runtime
- a web server
- a messaging platform
- a database
Instead, Kubernetes continuously compares two states.
Desired State
vs
Actual State
Whenever the two differ, Kubernetes takes action.
That simple idea is the foundation of self-healing.
Desired State vs Actual State
Suppose we deploy our Payment Service with three replicas.
Desired State
Payment Service
Replicas = 3
Actual State
Pod-1 Running
Pod-2 Running
Pod-3 Running
Everything matches.
No action required.
Now imagine Pod-2 crashes.
Desired = 3 Pods
Actual = 2 Pods
Immediately Kubernetes notices the difference.
It automatically creates another pod until the desired state is restored.
Notice something important.
Nobody logged into the server.
Nobody restarted anything.
Nobody even knew it happened.
This is self-healing.
High-Level Kubernetes Architecture
A Kubernetes cluster consists of two major sections.
Kubernetes Cluster
+-------------------------------+
| Control Plane |
+-------------------------------+
│
│
-------------------------------
Worker Node 1
Worker Node 2
Worker Node 3
Worker Node N
Think of it like an organization.
The Control Plane makes decisions.
Worker Nodes execute those decisions.
The Control Plane
The Control Plane is the brain of Kubernetes.
It contains several independent services.
+-------------------------------------------+
Kubernetes Control Plane
---------------------------------------------
API Server
Scheduler
Controller Manager
etcd
Cloud Controller (optional)
---------------------------------------------
Each service has a unique responsibility.
Let’s understand them one by one.
API Server
Every request enters Kubernetes through the API Server.
Imagine executing:
kubectl apply -f payment.yaml
The command never talks directly to a worker node.
Instead
kubectl
│
API Server
│
Stores configuration
│
etcd
The API Server validates every request before accepting it.
You can think of it as Kubernetes’ front door.
etcd
If the API Server is the front door…
etcd is the memory.
It stores:
- Deployments
- Pods
- Services
- ConfigMaps
- Secrets
- ReplicaSets
- Nodes
- StatefulSets
Everything Kubernetes knows about your cluster is stored inside etcd.
If etcd loses data, Kubernetes forgets the cluster.
This is why etcd backups are critical in production.
Scheduler
Suppose Kubernetes needs to create a new pod.
Where should it run?
Node 1?
Node 2?
Node 3?
The Scheduler decides.
It considers many factors.
- CPU availability
- Memory availability
- Node affinity
- Taints
- Tolerations
- Pod affinity
- Resource requests
- Resource limits
Example
Need New Pod
│
Scheduler
│
Node-2 has enough resources
│
Deploy Pod
Controller Manager
This is arguably the most important component for self-healing.
Controllers continuously compare
Desired State
vs
Actual State
Example
Deployment
Desired = 3 Pods
Current
Pod A
Pod B
Controller notices
Missing Pod
Immediately
Create Pod C
No human intervention.
This reconciliation loop runs continuously.
Worker Nodes
Worker Nodes execute application workloads.
+--------------------------------+
Worker Node
---------------------------------
kubelet
Container Runtime
Pods
Volumes
Networking
---------------------------------
Your Spring Boot applications never run inside the Control Plane.
They always execute on Worker Nodes.
kubelet
Every worker node runs kubelet.
Think of kubelet as the local Kubernetes agent.
Responsibilities
- Creates Pods
- Starts Containers
- Runs Health Probes
- Reports Pod Status
- Reports Node Status
- Restarts Failed Containers
If kubelet cannot communicate with the Control Plane, the node eventually becomes unhealthy.
Container Runtime
Containers don’t run themselves.
They require a runtime.
Examples
- containerd
- CRI-O (default in OpenShift)
- Docker (older clusters)
The runtime is responsible for
Image
↓
Container
↓
Running Process
If the Java process exits…
The runtime reports it.
kubelet notices.
Controller reacts.
Deployment restores the desired state.
How a Pod Gets Created
Let’s follow the complete lifecycle.
Developer
↓
kubectl apply
↓
API Server
↓
etcd
↓
Scheduler
↓
Choose Worker Node
↓
kubelet
↓
Container Runtime
↓
Start Pod
↓
Running
This entire process usually completes in a few seconds.
How Self-Healing Actually Works
Suppose Payment Service crashes.
Payment Pod
↓
JVM Crash
↓
Container Exits
↓
Container Runtime Detects Exit
↓
kubelet Reports Failure
↓
API Server Updated
↓
Controller Notices Missing Replica
↓
Scheduler Selects Node
↓
New Pod Created
↓
Traffic Restored
Notice how many components collaborate to recover a single pod.
Kubernetes is never “watching” your application through a single process.
Instead, dozens of controllers continuously reconcile cluster state.
Banking Example
Suppose our banking application has three Payment Service pods.
Payment Service
Pod-1
Pod-2
Pod-3
Suddenly Pod-2 crashes.
The customer never notices because:
Service
↓
Pod-1
Pod-3
↓
Traffic Continues
↓
Controller Creates Pod-4
↓
Cluster Back to Three Pods
This illustrates an important principle.
Users connect to a Service, not directly to a Pod.
We’ll explore Services and networking in upcoming articles.
Why Java Developers Should Care
Many Spring Boot developers assume Kubernetes behaves like Tomcat running on a VM.
It doesn’t.
Consider these realities:
- Your JVM may disappear at any time.
- Your application may restart on another machine.
- Local files may vanish.
- Pod IP addresses change.
- Containers are disposable.
Your application should never depend on any of these being permanent.
Production Best Practices
✔ Treat pods as temporary.
✔ Externalize configuration using ConfigMaps and Secrets.
✔ Keep services stateless.
✔ Persist data in databases, not local disks.
✔ Design startup to be fast.
✔ Always define CPU and memory requests.
✔ Assume pod IP addresses change.
Common Misconceptions
❌ Kubernetes restarts failed methods.
No. It restarts containers.
❌ Kubernetes fixes application bugs.
No.
It only restores infrastructure.
❌ Pods are permanent.
No.
Pods are disposable resources.
❌ One Deployment equals one server.
No.
A Deployment may span dozens of nodes.
❌ Containers should store persistent data.
Never.
Use Persistent Volumes or external databases.
Interview Questions
What is the difference between a Pod and a Deployment?
A Pod is the smallest deployable unit.
A Deployment manages Pods and ensures the desired number of replicas are always running.
Why does Kubernetes use etcd?
To persist the desired and actual cluster state.
What does kubelet do?
It manages Pods on a worker node and communicates with the Control Plane.
What is the Scheduler responsible for?
Selecting the best node for newly created Pods.
Which component performs self-healing?
The Controller Manager continuously reconciles the desired state with the actual state and initiates recovery actions.
Key Takeaways
- Kubernetes is a collection of specialized components working together.
- The Control Plane makes decisions; Worker Nodes execute workloads.
- Self-healing is driven by reconciliation between desired and actual state.
- Pods are temporary and should never hold business state.
- Java applications must be designed with the expectation that containers can disappear at any time.
What’s Next?
Now that we understand the architecture of Kubernetes, it’s time to look at its most fundamental building block.
In Part 3, we’ll explore:
- Pods
- ReplicaSets
- Deployments
- Namespaces
- Labels and Selectors
By the end of the next article, you’ll understand how Kubernetes manages application lifecycle and why a Deployment—not a Pod—is the correct way to run production Spring Boot applications.