Desired replicas vs actual replicas in Kubernetes - When to Use Which

The Big Idea

What if your app could fix itself when it's too busy or too quiet, without you doing anything?

The Scenario

Imagine you have a website that suddenly gets a lot of visitors. You try to start more copies of your website manually on different servers to handle the traffic.

You have to check each server one by one to see if the website is running, and start or stop copies as needed.

The Problem

This manual way is slow and tiring. You might forget to start enough copies or accidentally start too many, wasting resources.

Also, if a copy crashes, you might not notice quickly, causing your website to slow down or stop.

The Solution

Kubernetes solves this by letting you say how many copies (replicas) you want, called the desired replicas.

It then watches the actual replicas running and automatically starts or stops copies to match your desired number.

This keeps your website running smoothly without you checking all the time.

Before vs After

✗ Before

ssh server1
start website
ssh server2
start website

✓ After

kubectl scale deployment mysite --replicas=3

What It Enables

You can focus on your app while Kubernetes keeps the right number of copies running automatically.

Real Life Example

During a big sale, your online store needs more copies to handle many buyers. Kubernetes adjusts the copies up and down without you lifting a finger.

Key Takeaways

Manually managing copies is slow and error-prone.

Desired replicas tell Kubernetes how many copies you want.

Kubernetes keeps actual replicas matching desired replicas automatically.