- TechOps Examples
- Posts
- Kubernetes Optimization Reality
Kubernetes Optimization Reality
Govardhana M K
June 10, 2025
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.
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
IN TODAY'S EDITION
🧠 Use Case
Kubernetes Optimization Reality
🚀 Top News
👀 Remote Jobs
Invisible Technologies is hiring a Automation Engineer
Remote Location: Worldwide
Stakefish is hiring a Senior Site Reliability Engineer
Remote Location: United States, Canada, Argentina, Brazil, Mexico
📚️ Resources
🧠 USE CASE
Kubernetes Optimization Reality
Every Kubernetes engineer hits this wall eventually. You scaled your workloads. You deployed the apps. You enabled autoscaling.
And yet, your cluster costs keep creeping up. Resource usage graphs look bloated. Some nodes sit idle while pods still go pending. You think you did everything right. But optimization? It still feels out of reach. This is the reality of Kubernetes at scale.
Most teams start with the classic Cluster Autoscaler.
It’s simple, supported, and works with predefined node groups. It doesn’t care what your workloads actually need. It just adds or removes nodes based on requests. And those nodes? Always the same size. Always predefined. There’s no nuance. No dynamic provisioning. Just more of the same.
Karpenter changed that.
It’s fast, flexible, and less limited in its node type choices and considers cost too. You get diversity in instance types, spot instance support, and even consolidation logic that replaces underutilized nodes. It’s smarter. But it’s not flawless.
Because Karpenter still depends on your workload specs. If your pod requests are inflated, it provisions big nodes. If you have pending pods that don’t pack well together, it creates too many small ones. The autoscaling logic improves, but the core assumption doesn’t change, it trusts your declared requests. And that’s risky.
That’s the hidden cost. Most dashboards won’t show it. Your cloud bill will.
So what do you do?
Some teams run Goldilocks to recommend CPU/memory requests. Others write their own logic using the Kubernetes API, Prometheus queries, and cost telemetry from cloud billing exports.
You can use DataDog or Grafana to as they position themselves as visibility tools but they lack the proactivity. You still have to go and find the errors.
These tools don’t apply changes or optimize workloads. They give data, not decisions.
Here’s where the real pain persists.
Pain 1
You overprovision “just to be safe” and pay for what you never use. Clusters scale to fit declared requests, not actual usage.
Pain 2
Autoscalers react based on signals, but those signals are rarely accurate. Tuning consolidation, interruption handling, or scheduling policies takes effort.
Pain 3
Visibility tools like Prometheus, Grafana, or dashboards give you graphs, not decisions. You still need to interpret data, verify safe changes, and act manually.
PerfectScale solves all three pain points
It connects to your cluster and starts tracking real usage, not just what’s requested, but what is actually used consistently. It understands which workloads are bursty, which ones are resilient, and which are safe to downsize.
Then it gives you clear, risk-aware actions. Like:
Reduce CPU request for order-service from 500m to 200m
Decrease memory allocation on payments-api from 1Gi to 512Mi
Consolidate 3 small nodes into one bigger node
Switch a workload safely to spot nodepool
And it doesn’t stop at suggesting, it can apply these actions automatically, if you allow.
The results are clear. As shown in the chart, after enabling PerfectScale:
CPU requests come closer to real usage
Pods bin-packing is improving
Node count starts dropping
No drop in availability
The best part - you gain cost savings without compromising safety.
Not only that, you get a clear visual breakdown of resource usage by node group, type, or environment across the selected timeframe, making it easier to spot inefficiencies and plan optimizations.
No custom logic. No extra scripts. It works alongside Karpenter or Cluster Autoscaler.
If you want Kubernetes to be truly cost-efficient without playing guessing games, PerfectScale closes that loop.
Once installed, you can set optimization policies to tailor optimization with business goals:
MaxSavings for dev clusters
Balanced for production
ExtraHeadroom for latency-sensitive systems
MaxHeadroom for critical workloads
How to set it up
1. Install in minutes using Helm
helm upgrade --install -n perfectscale --create-namespace perfectscale
--set secret.create=true
--set secret.clientId=****
--set secret.clientSecret=****
--set settings.clusterName=your-cluster-name
perfectscale/exporter
You can customize the setup for mixed node pools, tolerations, Windows containers, or external kube-state-metrics.
2. Connect to cloud
Grant read-only access to cloud cost APIs (like AWS Cost Explorer or Azure Billing)
Configure using Helm values or through their UI
3. Start automation
Configure Automation tailored your business goals with flexible CRD
Apply automation to your cluster(s)
Explore Automation KPIs with a granular dashboard