FinOps for Kubernetes: Autoscaling Kubernetes Workloads (HPA & VPA)

finops for kubernetes

Someone asked how FinOps connects to autoscaling in Kubernetes.

Think about what happens when your application suddenly gets a surge in traffic , maybe during a product launch, a viral moment, or a spike in transactions. If autoscaling isn’t in place, you’re forced into a bad trade-off: either you under-provision and risk performance issues or outages, or you over-provision and pay for resources that sit idle most of the time.

Autoscaling helps you match infrastructure usage to real demand in real time, which is exactly where FinOps comes in; optimizing cost without sacrificing performance

In this hands-on guide, we’ll walk through how to build a self-scaling system on Microsoft Azure using Azure Kubernetes Service (AKS). You’ll implement Horizontal Pod Autoscaler (HPA) to handle traffic spikes and Vertical Pod Autoscaler (VPA) to optimize resource usage; all in a real cloud environment. Think of this as moving from static infrastructure to intelligent, responsive systems.

In this lab, we will:

• Provision an AKS cluster on Microsoft Azure
• Deploy a sample workload
• Configure HPA (Horizontal Pod Autoscaler)
• Configure VPA (Vertical Pod Autoscaler)
• Simulate real traffic
• Observe scaling behavior in a cloud environment

Prerequisites

• Azure account
• Azure CLI installed
• kubectl installed
• Basic knowledge of Kubernetes

login

az login

The command above will help you login to azure in your local environment

Step 1: Create AKS Cluster

a.Create Resource Group

az group create --name aks-autoscale-rg --location eastus

b. Create AKS Cluster

👉 This cluster has an addon for Azure Monitor for observability.

az aks create \
  --resource-group aks-autoscale-rg \
  --name aks-autoscale-cluster \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --enable-addons monitoring \
  --generate-ssh-keys

cluster created

c. Connect to Cluster

az aks get-credentials --resource-group aks-autoscale-rg --name aks-autoscale-cluster

connected

d. Verify

Run kubectl get nodes to ensure nodes are Ready.

kubectl get nodes

Step 2: Deploying the Workload

The hpa-example image is perfect for testing because it is pre-configured to perform intensive CPU-hogging tasks when hit with traffic.

a. Deploy the Application

kubectl create deployment autoscale-demo --image=registry.k8s.io/hpa-example

created

a. Set Resource Requests (CRITICAL) Autoscalers require baseline CPU data to make decisions.

kubectl set resources deployment autoscale-demo --requests=cpu=100m,memory=128Mi --limits=cpu=500m,memory=512Mi

baseline created

c. Expose the Application (Stable Port Mapping) The app listens on port 8080 internally. We expose it on port 80 for the service

kubectl expose deployment autoscale-demo --port=80 --target-port=8080 --type=LoadBalancer

exposed

d. VERIFY Before Proceeding Ensure the service exists with a simple hyphen (-):

kubectl get svc autoscale-demo

service exist

Step 3: Configure Horizontal Pod AutoScaler(HPA)

HPA behaves like a “First Responder” — it adds more pods to share the load during traffic spikes.

a. Define the HPA Policy We will tell K8s: “If average CPU usage across pods exceeds 50%, add up to 10 pods.”

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

autoscale poilcy set

b. Verify Setup

kubectl get hpa

verified

c. Simulate Load (The Stress Test) Open a NEW terminal window (do not stop this command once started):

kubectl run -i --tty load-generator --rm --image=busybox:1.28 -- /bin/sh -c "while true; do wget -q -O- http://autoscale-demo.default.svc.cluster.local; done"

IMPORTANT

Why is it scrolling OK!OK!OK!? This is success! The command is hitting the service non-stop to spike the CPU. Leave this terminal running for about 5 minutes to see results.

Note: Incase you encounter any error delete the resources and recreate them again before re-running the generator or even kubectl get hpa -w

# 1. Start Fresh kubectl delete deploy autoscale-demo — ignore-not-found kubectl delete hpa autoscale-demo — ignore-not-found

# 2. Deploy with CPU requests (CRITICAL) kubectl create deployment autoscale-demo — image=registry.k8s.io/hpa-example kubectl set resources deployment autoscale-demo — requests=cpu=100m kubectl expose deployment autoscale-demo — port=80

# 3. Create the HPA (Target 50% CPU, Min 1, Max 10) kubectl autoscale deployment autoscale-demo — cpu-percent=50 — min=1 — max=10

d. Watch Scaling (In your ORIGINAL terminal)

# Watch the CPU percentage rise
kubectl get hpa -w

replicas created

Step 4: Vertical Pod Autoscaling (VPA)

VPA optimizes a single pod’s size. It looks at historical data and says: “This pod is actually using 200MB, not 128MB. Let me update its request size.”

a. Enable the Managed VPA Add-on

az aks update --resource-group aks-autoscale-rg --name aks-autoscale-cluster --enable-vpa

enabled vpa

b. Create the VPA Configuration

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: autoscale-demo-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: autoscale-demo
  updatePolicy:
    updateMode: "Initial"

apply the changes

c. View Recommendations Wait 2–3 minutes, then run:

kubectl describe vpa autoscale-demo-vpa

a view of the recommendation

Step 5: Cluster Autoscaler (CA)

CA is the Infrastructure Scaler. If HPA tries to scale to 10 pods but the nodes are full, CA adds more virtual machines to your cluster.

az aks update \
  --resource-group aks-autoscale-rg \
  --name aks-autoscale-cluster \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

created

Step 6: Cleanup

Avoid Azure costs by deleting the resource group:

az group delete --name aks-autoscale-rg --yes --no-wait

Conclusion

Ultimately, the synergy between HPA and VPA provides the most robust framework for Kubernetes cost management. While HPA ensures you have the necessary reach to handle demand, VPA ensures that each individual pod is optimized for the exact resources it needs, preventing the hidden ‘cost creep’ of over-provisioning. In a true FinOps culture, this automated right-sizing and elastic scaling allow engineering and finance teams to share a common goal: delivering maximum workload value at the lowest possible price point. By leveraging these native Kubernetes autoscaling capabilities, you’re not just building a more resilient application; you’re building a fiscally responsible foundation that scales with your business, not just your bill.