TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Upgrade your AI knowledge with The CODE! Dive into a newsletter trusted by 350,000+ readers for its comprehensive, 5-minute snapshot of everything happening in AI. We navigate through hundreds of sources to bring you the latest AI trends, tools, and resources—so you can stay ahead, absolutely free.

Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us

A cluster with a fixed number of nodes and a fixed number of replicas per deployment has to be sized for the worst traffic day of the year, every other day it runs mostly idle capacity that still shows up on the bill.

Kubernetes ships three separate autoscaling mechanisms, each solving a different layer of this problem, pod resource size, pod replica count, and node count, and none of them alone is sufficient. Understanding what each one actually watches and changes is what makes it possible to combine them without one undoing the work of another.

A Vertical Pod Autoscaler (VPA) answers a narrow question: is this pod's CPU and memory request set correctly, based on what it actually uses? A request set too low means the pod gets throttled or OOM killed under real load, a request set too high wastes reserved capacity nobody consumes. Instead of a person guessing at these numbers once and never revisiting them, the VPA watches actual usage continuously and adjusts.

The VPA runs in one of three modes worth distinguishing.

A Horizontal Pod Autoscaler (HPA) answers a different question: given current load, how many replicas of this pod does the deployment need right now? Rather than changing what one pod is allowed to consume, it changes how many pods exist.

The actual replica calculation follows a fixed formula, and it is worth working through with real numbers. Creating an HPA with:

kubectl autoscale deployment deployment_name --cpu-percent=50 --min=1 --max=10

tells Kubernetes to keep average CPU usage across all replicas near 50 percent, scaling anywhere between 1 and 10 pods to hold that target. The formula the HPA controller applies is:

desiredReplicas = ceil[ currentReplicas × ( currentMetricValue / desiredMetricValue ) ]

Say the deployment starts at 1 replica and CPU usage climbs to 210 percent of the requested value, the HPA computes ceil[ 1 × (210 / 50) ] = ceil[4.2] = 5 replicas, and scales up accordingly.

If usage then drops to 25 percent while running those 5 replicas, the next evaluation computes ceil[ 5 × (25 / 50) ] = ceil[2.5] = 3 replicas, and the deployment scales down to 3.

Each scaling decision is recalculated fresh against the current replica count, not against the original baseline, which is why a sudden spike gets a fast, large correction while a gradual decline scales down in smaller steps across several evaluation cycles.

Not safely on the same metric. Running both against CPU or memory creates a feedback loop, the VPA changes the pod's CPU request, which shifts what "50 percent" actually means in absolute terms, which changes when the HPA decides to scale, which changes the aggregate CPU the VPA observes next. The two controllers end up reacting to numbers that moved for reasons unrelated to real load. The supported combination is running VPA on CPU and memory while pointing the HPA at a separate, uncorrelated metric, request rate, queue depth, or a custom application metric through the custom metrics API, so the two autoscalers are never adjusting against the same signal. Some managed VPA implementations also expose a ContainerResourcePolicy restricted to memory only, paired with an HPA scaling on CPU, as another way to keep the two from colliding.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)