Kubernetes Rightsizing & Autoscaling: The Most Profitable FinOps Strategy · Daniel Tinizaray

Why Kubernetes Spirals Your Bill if Left Unchecked

Kubernetes is extraordinarily capable. It orchestrates containers, scales services, manages networking, and deploys across multi-cloud environments effortlessly. But without proper resource configuration for each workload, your cluster becomes an engine of unnecessary spending.

The numbers from the 2026 State of Kubernetes Optimization Report are stark: 69% of clusters over-provision CPU, 79% over-provision memory, and average CPU utilization in production sits at 8%. You are billed for what you reserve, not what you use. And Kubernetes, by default, does not protect you from yourself.

The Four Waste Layers in Kubernetes

To optimize costs effectively, you must first identify which layer generates the waste. These are the four main drivers:

• Over-provisioned pods: CPU/memory requests far above actual consumption. The most common and easiest to fix.
• Oversized nodes: EC2/GCE instances larger than what the cluster's actual load requires.
• Unnecessary on-demand pricing: Stateless workloads running on on-demand instances when they could use spot instances at up to 70% discount.
• Idle GPUs: Reserved but underutilized GPUs — a growing problem as AI/ML workloads enter production.

Rightsizing: The Highest-Confidence Win

Rightsizing — adjusting each pod's requests and limits to match actual consumption — remains the most reliable cost-saving lever in 2026. It requires no architectural changes or workload migrations. Just data and the will to act.

Most teams make the same mistake: they set requests based on estimates during development. A microservice consuming 200m CPU on average might have a request of 1 CPU "just in case." That safety margin, multiplied across hundreds of pods, translates to tens of thousands of dollars annually.

The correct workflow is:

1. Deploy a metrics agent (Metrics Server, Prometheus) and collect historical consumption data.
2. Analyze P50, P95, and P99 percentiles for CPU and memory per workload.
3. Set requests to the P85-P95 percentile, limits to twice the request.
4. Deploy VPA (Vertical Pod Autoscaler) in "recommender" mode initially.
5. Automate recommendation application after a 7-day observation period.

Autoscaling: Horizontal vs Vertical

Autoscaling complements rightsizing. There is no point in adjusting resources if the cluster cannot scale on demand. Two main approaches:

Horizontal Pod Autoscaler (HPA)

Scales replicas based on CPU/memory metrics or custom metrics (RPS, latency, queue depth). It is the most widely used mechanism and works well for stateless workloads with predictable traffic patterns.

Recommended configuration: targetUtilization at 60-70% for CPU, minimum 2 replicas, maximum based on budget. Use custom metrics for latency-sensitive services.

Vertical Pod Autoscaler (VPA)

Adjusts requests and limits of existing pods without changing replica count. Ideal for stateful workloads (databases, queues) where horizontal scaling is complex.

Operating modes: "off" (recommend only), "auto" (applies changes with pod recreation), "initial" (applies at creation only). Start in "off" mode, migrate to "auto" with disruption budgets.

Cluster Autoscaler / Karpenter

Scales the number of cluster nodes. Karpenter has gained significant traction in 2026 for its ability to provision instances from different families based on pod requirements, optimizing packing and reducing underutilized nodes.

Closed-Loop FinOps Automation

Manual optimization does not scale. Teams that keep costs under control in 2026 share one trait: closed-loop automation.

• Insight → action: Tools that only visualize costs (dashboards) do not reduce the bill. You need platforms that automate changes based on metrics.
• Governance policies: Define limits per namespace, team, or environment. Block deployments that exceed certain CPU/memory thresholds without approval.
• Spot instances for batch workloads: Scraping workers, nightly processing, CI/CD, and model training can run on spot with savings up to 70%.
• Monthly budgets per team: Implement real chargeback/showback. When teams see their own spending, optimization happens naturally.

Common Mistakes and How to Avoid Them

• Overprovisioning "for safety": High requests do not improve resilience. Use limits to protect noisy neighbors and realistic requests based on historical data.
• Autoscaling without cooling period: Configure stabilization windows (30-60 seconds) to avoid thrashing and unnecessary scaling costs.
• Ignoring egress costs: Cross-cloud traffic is expensive. Keep workloads and data in the same region whenever possible.
• Multi-cloud as default: Use multi-cloud for resilience and regulatory requirements, not as a cost-saving strategy. It is almost never cheaper.

Recommended Tools for 2026

• Cast AI: Autonomous optimization platform with continuous rightsizing, spot automation, and multi-cloud analysis.
• Kubecost + OpenCost: Granular cost visibility by namespace, deployment, and label. Great for chargeback/showback.
• Karpenter: Node lifecycle manager that selects optimal instance types for each pod, reducing underutilized nodes.
• VPA + Goldilocks: Goldilocks wraps VPA with a UI for visualizing resource recommendations.
• CloudZero: Cost allocation based on business units rather than infrastructure constructs.

Conclusion

Kubernetes cost optimization in 2026 is no longer a one-time cleanup sprint. It is a continuous process combining rightsizing, intelligent autoscaling, closed-loop automation, and team-level governance. Visibility-only tools are no longer sufficient — you need platforms that automate optimization decisions.

Start by measuring your actual utilization, adjust requests based on historical data, implement progressive autoscaling, and automate everything that can be automated. The results — between 50% and 75% infrastructure cost reduction — speak for themselves.