Before learning the tool, it helps to feel the problem that the tool removes.

Applications have busy days and quiet days

Almost every application faces uneven demand. A shopping website is flooded during a festival sale and nearly empty at three in the morning. A tax-filing portal is quiet for most of the year and overloaded in the last week before the deadline. A school results website may sit idle for eleven months and then receive a million visitors in one hour. If you always run enough copies for the busiest moment, you waste money for most of the year. If you always run enough copies for the quiet moments, the service collapses when the crowd arrives.

What a copy really is

In Kubernetes, your program runs inside a small unit called a Pod. To handle more visitors, you do not make one Pod bigger; you run more identical Pods side by side, and a Service shares the visitors between them. Each Pod is called a replica, and the number of replicas is a single setting. Changing that setting is what scaling means in this context.

Why deciding by hand is sometimes best

Many people assume that automatic scaling is always better than manual scaling. It is not. Automatic tools react to what has already happened: they notice load after it arrives. A human, on the other hand, knows things the computer cannot know, such as “our advertisement goes live on television at eight tonight” or “the database will be under maintenance on Sunday”. Manual scaling gives you predictability, control and simplicity, and it is the foundation that every automatic scaler is built upon.

Manual scaling means a person deliberately changes how many replicas of a workload should run.

The plain definition

Manual scaling is the act of a human, or a script that a human controls, setting the desired number of replicas for a workload such as a Deployment. You state a new number, Kubernetes accepts it, and its controllers work to make reality match that number by creating or removing Pods. Nothing measures your traffic or your processor use. The number stays exactly where you put it until someone changes it again.

Desired state versus actual state

Kubernetes works on a simple principle. You describe the state you want, called the desired state, and the cluster constantly compares it with the state that actually exists, called the actual state. Whenever the two differ, controllers take action to close the gap. When you scale manually, you only change the desired state. The controllers do the real work.

Where it is used

Teams use manual scaling before planned events, during emergencies, in test and development environments, for applications with steady and predictable demand, and whenever they want a precise, fixed capacity. It is also used in cost-saving routines, such as shutting down non-production workloads at night and bringing them back in the morning.

Scaling has two directions and two styles. Mixing them up is the most common source of confusion for newcomers.

Two directions

Two styles

To understand what happens when you change a number, you need a quick picture of the cluster around it.

The main players

A Kubernetes cluster has a control plane, which is the brain, and worker machines called nodes, which are the muscles. Several parts cooperate whenever you scale a workload. The cards below introduce each one in simple words.

flowchart LR
  U["Operator changes replica number"] --> A["API Server"]
  A -->|"save desired state"| E[("etcd database")]
  A --> D["Deployment controller"]
  D --> R["ReplicaSet controller"]
  R -->|"create or delete Pods"| A
  A --> S["Scheduler"]
  S -->|"pick a node"| K["Kubelet on node"]
  K --> P["Pods running"]
        

Read the picture from left to right. The operator changes the number, the API Server saves it, and controllers notice the change. The ReplicaSet controller compares the desired count with the actual count and asks for Pods to be created or deleted. The scheduler picks a machine for each new Pod, and the kubelet on that machine starts it. No single part does everything, and each part only reacts to what it sees.

Not every Kubernetes object has a replica number. Knowing which ones do saves confusion.

Kubernetes has several kinds of workload objects, each designed for a different purpose. Some of them have a replica number that you can change, and some do not, because their design forbids it.

Why a Deployment is the usual choice

A Deployment sits on top of ReplicaSets and gives you rolling updates, rollback and easy scaling in one object. It is designed for stateless programs, meaning programs where any copy can answer any request equally well. Because the copies are interchangeable, adding or removing them is safe and simple.

Now that you know the players, let us follow one scaling request from your keyboard to running Pods.

The journey step by step

sequenceDiagram
  participant Op as Operator
  participant API as API Server
  participant DC as Deployment controller
  participant RC as ReplicaSet controller
  participant Sch as Scheduler
  participant Kub as Kubelet
  participant Svc as Service
  Op->>API: Set replicas from 3 to 6
  API->>DC: Desired state changed
  DC->>RC: Update ReplicaSet target
  RC->>API: Create 3 new Pods
  API->>Sch: Pods need a node
  Sch->>API: Assign nodes
  API->>Kub: Start assigned Pods
  Kub->>API: Pods report ready
  API->>Svc: Add ready Pods as targets
        

An important fact: scaling is not a rollout

When you change only the replica number of a Deployment, the Pod template stays the same. Kubernetes therefore does not create a new version, does not replace existing Pods and does not restart anything. It simply adds or removes copies. This is why scaling is fast and low-risk compared with updating the application itself.

There is more than one road to the same destination. Each road suits a different way of working.

Imperative versus declarative

The first, second, fifth and sixth methods are imperative, meaning you give a direct command to the live cluster. The third and fourth are declarative, meaning you describe the wanted end state in a file and let tools apply it. Both are valid, but they behave very differently over time.

Safety checks you can add

The scale command can include useful conditions. You can ask it to act only if the current number is what you expect, so that two people scaling at the same moment do not overwrite each other. You can also give it a time limit to wait for the change to finish. These small options turn a blunt instrument into a careful one.

Asking for more copies does not guarantee getting them. Several things can stand in the way.

When you raise the number, Kubernetes creates new Pod objects immediately, but a Pod object is only a promise. To become a working copy, it needs room on a machine, permission to use resources, an available image and a passing health check. If any of these fail, the Pod waits in a state called Pending or fails to become ready.

flowchart TD
  N["New Pod created"] --> Q{"Namespace quota allows it?"}
  Q -->|"No"| X1["Pod refused"]
  Q -->|"Yes"| F{"Node with enough free room?"}
  F -->|"No"| X2["Pod stays Pending"]
  F -->|"Yes"| I{"Image downloads and starts?"}
  I -->|"No"| X3["Image pull problem"]
  I -->|"Yes"| H{"Readiness check passes?"}
  H -->|"No"| X4["Running but receives no traffic"]
  H -->|"Yes"| OK["Pod serves visitors"]
        

Removing copies looks easy, but it is where careless scaling hurts real users.

Which Pods are removed first?

When the desired number drops, the ReplicaSet controller must choose which Pods to delete. It does not choose randomly. It follows a set of preferences, roughly in this order. Pods that are not yet placed on any node go first. Pods that are not ready go before ready ones. Pods whose owners have given them a lower deletion priority go earlier. Pods on nodes that already hold many copies go before Pods on lightly loaded nodes, which helps keep the spread even. Newer Pods tend to go before older ones, and Pods that have restarted many times may go earlier.

You can influence this choice. Kubernetes lets you attach a special note to a Pod, called a deletion cost, so that Pods you consider cheaper to lose are removed first. This is a hint, not a strict guarantee, but it is helpful when some Pods hold warm caches or long-running work.

Graceful termination

A Pod selected for removal is not killed at once. Kubernetes first marks it as terminating and removes it from the Service so that no new visitors arrive. It then sends a polite stop signal to the program and waits for a grace period, thirty seconds by default, so the program can finish current requests and close connections. Only if the program is still running after that time is it stopped forcibly.

A surprising limit: disruption budgets do not apply

Kubernetes offers an object called a Pod Disruption Budget, which says “never let fewer than this many Pods be available during voluntary disruptions”. It protects Pods during maintenance actions such as draining a node. However, scaling down through a Deployment is not treated as that kind of disruption. The controller simply deletes Pods, and the budget does not stop it. You must therefore choose scale-down numbers carefully yourself.

Setting the number to zero is a legitimate and useful move, but it has consequences worth knowing.

What zero means

Scaling a Deployment to zero removes every Pod but keeps the Deployment object, its settings and its history. The application is effectively switched off, yet it is remembered exactly as it was. Raising the number again brings the Pods back. It is the cleanest way to pause a workload without deleting anything.

Why teams do it

What to expect while at zero

With no Pods, the Service behind the application has no addresses to send visitors to, so requests fail. Scheduled work and background processing stop. Any cache the application kept in memory is lost. When you scale back up, the application starts from cold, which can take time and may cause a burst of load on databases as caches refill.

Programs that remember things, such as databases, need extra care when their number of copies changes.

Why stateful is different

The copies of an ordinary Deployment are interchangeable. The copies of a database cluster are not. Each one may hold different data, have a fixed name and take a specific role, such as leader or follower. Kubernetes handles such programs with a StatefulSet, which gives every Pod a stable name, a stable network identity and its own storage.

The careful order

By default, a StatefulSet scales up one Pod at a time, in numbered order, and waits for each Pod to become ready before starting the next. When scaling down, it removes Pods in the reverse order, highest number first. This protects data and lets clustered programs join or leave gracefully. A setting exists to let Pods start and stop in parallel when order does not matter, but the careful order is the safe default.

Storage stays behind by default

Each Pod of a StatefulSet usually has its own persistent storage. When you scale down, the Pod disappears but its storage is normally kept, so that scaling back up reconnects the same data. Newer versions of Kubernetes include a policy that lets you choose to delete the storage automatically when scaling down, but keeping it is the cautious default and deleting data should be a conscious decision.

Sometimes you need to change the number while a new version is still being rolled out. Kubernetes has a rule for that.

During a rolling update, a Deployment temporarily runs two ReplicaSets: the old version, which is shrinking, and the new version, which is growing. If you change the replica number at that moment, Kubernetes does not dump all the extra Pods on one side. Instead, it shares the change between the two ReplicaSets in proportion to their current sizes. This is called proportional scaling, and it keeps the update healthy while the capacity changes.

flowchart LR
  A["Deployment wants 10 copies"] --> B["Old ReplicaSet with 6 Pods"]
  A --> C["New ReplicaSet with 4 Pods"]
  D["Operator raises number to 15"] --> E["Change shared in proportion"]
  E --> F["Old ReplicaSet gets a larger share"]
  E --> G["New ReplicaSet gets a smaller share"]
        

Practical advice

Although Kubernetes handles this situation gracefully, it is usually wiser to avoid scaling in the middle of an update. Finish the rollout, confirm that everything is healthy, and then change the number. Two changes at once make it much harder to tell which one caused a problem.

The biggest surprise for beginners is that their manual change may quietly disappear. Here is why.

The autoscaler fights back

If a Horizontal Pod Autoscaler is attached to a Deployment, it owns the replica number. Every few moments it measures load and sets the number according to its rules. If you change the number by hand, the autoscaler notices and simply overwrites your value with its own calculation. Your change survives only until the autoscaler’s next decision, which is usually within seconds or minutes.

To take manual control of such a workload, you must first pause or remove the autoscaler, or adjust its minimum and maximum limits to force the number you want. A common trick for a temporary boost is to raise the autoscaler’s minimum number, since it will never scale below that.

A subtle trap in definition files

If your definition file contains a fixed replica number and an autoscaler is also present, every time you apply the file the number is reset to the file’s value, undoing the autoscaler’s work. The recommended practice is to leave the replica number out of the file entirely when an autoscaler manages it, so that applying the file does not interfere.

GitOps tools restore what Git says

GitOps tools continuously compare the cluster with a repository and can be configured to correct any difference automatically. If you scale by hand and the repository says a different number, the tool may quietly set the number back. The right way to scale in such environments is to commit the change to the repository.

More Pods need more room. Sometimes the real scaling job is adding machines.

Pods run on nodes, and each node has a fixed amount of processor power and memory. When you raise the replica number beyond what the current nodes can hold, the extra Pods stay Pending. There are two ways to add room. An automatic node scaler, often called a cluster autoscaler, watches for Pending Pods and asks the cloud provider for new machines, then removes machines that sit empty. Alternatively, you can add nodes by hand, by changing the size of a node group in your cloud console or infrastructure tooling.

The hardest part of manual scaling is not the command. It is deciding the number.

Because scaling can stop an entire service or run up a large bill, it deserves proper access control.

Who may scale?

Kubernetes uses role-based access control to decide what each person or program may do. Scaling is a separate permission on a special part of the object called the scale subresource. This means you can give a person the right to change only the replica number, without letting them edit the rest of the Deployment. It is a neat way to let on-call staff respond to incidents without granting broad powers.

The risks

After you turn the dial, you must watch what happens. Here is what to look at and how to read the signs.

The numbers a Deployment reports

A Deployment reports several counts, and understanding the difference between them is the key to reading its health.

Common symptoms and their usual causes

What to watch after a change

After scaling, keep an eye on response times, error rates, processor and memory use per Pod, queue lengths, restart counts and the load on downstream systems. A healthy scale-up shows falling response times and a stable error rate. A worrying one shows rising errors, restarts or a growing number of Pending Pods.

These mistakes appear again and again in real clusters. Learn to recognise them early.

A short checklist of good habits, in the order you are likely to need them.

See how ordinary teams use manual scaling every day.

Every approach has strengths and limits. Knowing both keeps your expectations realistic.

Quick answers to the questions beginners ask most often.

No. Changing only the replica number adds or removes Pods without touching the ones that keep running, because the Pod template has not changed.

Most likely an autoscaler, a GitOps tool or a re-applied definition file overwrote it. Check who else controls the number, and change it at the source.

Yes. All Pods are removed but the Deployment remains, so raising the number later brings the application back. Requests fail while it is at zero.

Kubernetes prefers Pods that are not yet placed, not ready, on crowded nodes or newer, and you can give some Pods a lower deletion cost as a hint to remove them earlier.

The cluster probably lacks free room, a quota is reached or a placement rule cannot be met. The Pod’s events explain the exact reason.

Not by a replica number. A DaemonSet runs one Pod on each matching node, so you change the count by changing the number of nodes or the rule that selects them.

Neither is always better. Manual suits planned events, steady workloads and emergencies. Automatic suits unpredictable daily variation. Many teams combine both.

No. Disruption budgets protect against voluntary evictions such as draining a node, but a Deployment removing Pods to match a lower number is not blocked by them.

Scaling changes how many copies run. Updating changes what each copy is, such as a new image version, and triggers a rolling replacement of Pods.

They add Pods one at a time in numbered order and remove them in reverse order by default, and they normally keep each Pod’s storage when scaling down.

When scaling up, add machines first so that room exists. When scaling down, remove Pods first and only afterwards shrink the machines.

No. If the real bottleneck is a database or an external service, adding copies may not help and can even make the problem worse.

You began this guide at a tea stall, deciding for yourself how many helpers to call for a busy day. Manual scaling in Kubernetes is that same decision, made with a single number: how many copies of your application should run. You saw how the request travels through the API Server, the controllers, the scheduler and the kubelet, how a scale-up can be blocked by room, quotas, images or health checks, and how a scale-down chooses Pods and stops them gracefully. You learned the special rules for scaling to zero, for stateful applications and for rolling updates, and you discovered why a manual change can vanish when an autoscaler or a GitOps tool also owns the number. Above all, you learned that the command is the easy part: the real skill is choosing the right number, at the right time, with the right room underneath, and recording the change so that the cluster and its files always agree.