Komodor is an autonomous AI SRE platform for Kubernetes. Powered by Klaudia, it’s an agentic AI solution for visualizing, troubleshooting and optimizing cloud-native infrastructure, allowing enterprises to operate Kubernetes at scale.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Guides, blogs, webinars & tools to help you troubleshoot and scale Kubernetes.
Tips, trends, and lessons from the field.
Practical guides for real-world K8s ops.
How it works, how to run it, and how not to break it.
Short, clear articles on Kubernetes concepts, best practices, and troubleshooting.
Infra stories from teams like yours, brief, honest, and right to the point.
Product-focused clips showing Komodor in action, from drift detection to add‑on support.
Live demos, real use cases, and expert Q&A, all up-to-date.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Discover our events, webinars and other ways to connect.
Here’s what they’re saying about Komodor in the news.
Join the Komodor partner program and accelerate growth.
The median enterprise GKE cluster wastes between 30% and 60% of its allocated compute. Most teams find out from the invoice, not from their monitoring.
This guide walks through how to measure, diagnose, and reduce your Google Kubernetes Engine spend without torching your reliability in the process, from building an accurate GKE cost estimate to implementing the monitoring and automation that keeps costs from quietly climbing back up the moment you stop looking.
Running Kubernetes on Google Cloud gives your engineering org a lot of flexibility. It also gives it a lot of rope.
Most of the GKE cost problems at scale are not caused by engineers making bad decisions on purpose. They are caused by good decisions made in isolation, without visibility into the cumulative effect on infrastructure spend.
Let’s say a team migrates a set of services to GKE, provisions a node pool for a load test, and forgets to tear it down. It costs $400 a month and nobody notices for six months.
A second team sets resource requests conservatively low to avoid OOMKills, which causes the Cluster Autoscaler to spin up nodes that the workloads never actually needed.
A third team enables a feature flag at 2 AM that doubles the replica count across a dozen services, and nobody connects it to the cost spike until the invoice arrives two weeks later.
None of these are failures of intent. They are failures of visibility and coordination, and they compound into something much harder to unwind than any one of them was on its own.
The other piece of this is that GKE’s flexibility means the default configuration is almost never the optimal configuration. Clusters are spun up with sensible defaults, workloads get deployed, traffic arrives, and teams move on to the next sprint.
The result is a cluster that works reliably and consistently, but costs more than it needs to. Also, the gap between working and working efficiently tends to grow with every quarter of feature delivery that takes priority over infrastructure hygiene.
Before getting into the deeper work, here are three things that take under an hour each and almost always surface recoverable spend.
GKE cost allocation is turned off by default and takes about five minutes to enable in Google Cloud Billing. Once enabled, it starts attributing compute, memory, and storage costs to the namespaces and labels of the workloads consuming them.
If you do not have this enabled yet, enable it before doing anything else. Every optimization decision you make without it is based on incomplete information.
Run kubectl get pvc –all-namespaces | grep -v Bound and look at what comes back. Unbound PVCs, meaning those with no currently attached pod, persist after pods are deleted and continue generating storage charges indefinitely.
In environments with active development workflows, abandoned feature branch deployments, and regularly recycled staging environments, the number of orphaned PVCs tends to be higher than anyone expects.
Deleting confirmed orphans is low-risk, recovers immediate spend, and takes less time than the next incident review.
Go to Billing → Budgets and Alerts, set a budget for your GKE project, and configure threshold notifications at 50%, 90%, and 100%. This is not a sophisticated monitoring solution, but it is significantly better than finding out about a cost anomaly at the end of the billing cycle.
The five minutes it takes to configure this buys you a meaningful reduction in the time between when the cost problem starts and when someone finds out about it.
Beyond the quick wins, GKE cost optimization requires understanding your full cost structure. That means not just node compute, but every billable dimension of running workloads at scale.
A GKE cost estimate that only looks at node costs will undercount your actual spend by a meaningful margin.
Node costs are the obvious starting point, but they are rarely the whole story. You also need to account for persistent disk storage attached to your workloads, load balancer provisioning (Google charges per forwarding rule, per hour), egress traffic between regions or out to the internet, and the GKE management fee for standard clusters (approximately $0.10 per cluster per hour as of current Google Cloud pricing).
For multi-region setups, inter-region egress costs can be surprisingly high, particularly for microservice architectures where services are chatty across zone boundaries.
The Google Cloud Pricing Calculator is a useful starting point for your GKE cost estimate, but it will only give you an accurate number if you feed it accurate inputs. That means knowing your actual node utilization, not your requested utilization.
In a poorly-tuned cluster, these two numbers can differ by a factor of three or more, which means your cost estimate is off by the same factor if you use requested rather than actual utilization as your input.
GKE cost allocation features, specifically the namespace-level and label-based cost breakdown available through Google Cloud’s cost management tools, are underused in most organizations.
When you enable cost allocation in your billing settings, Google Cloud starts attributing compute, memory, and storage costs to individual namespaces, making it possible to charge costs back to specific teams or products.
This shifts the conversation from “we need to cut costs somewhere” to “here is exactly where the spend is going, and here is who owns it”, which is a much more productive starting point for any optimization effort.
It also creates the foundation for a chargeback or showback model, which is the organizational mechanism that gives individual teams a reason to care about the cost implications of their workload configuration.
The gap between “we have a cost problem” and “we know we have a cost problem” is where most of the money leaks out. Effective GKE cost monitoring means you find out about cost anomalies in hours, not at the end of the billing cycle.
Google Cloud’s built-in budgets and alerts (covered in the quick wins above) are the floor, not the ceiling. For more granular monitoring, most engineering teams combine Cloud Billing export to BigQuery with a Looker Studio dashboard or a Grafana integration.
Exporting billing data to BigQuery gives you a queryable record of every billable resource event, which means you can write queries that surface cost spikes at the namespace or label level, identify which node pools are consuming the most budget, and track spend trends over time with the granularity you actually need.
The key metric to watch is cost-per-workload over time, not just aggregate cluster spend. Aggregate numbers smooth over the kind of per-service anomalies that are most expensive to miss, like the replica count that doubled overnight, the node pool that never got decommissioned, and the batch job that started running twice as frequently after a deployment. You need the per-workload view to catch those.
Having cost data is not the same as understanding it. A common mistake in GKE cost analysis is treating all compute costs as equally actionable.
Some costs are structural, so you need a certain number of nodes to meet your availability and performance SLOs, and cutting below that number creates incidents rather than savings.
Other costs are discretionary, like idle replicas, over-provisioned resource requests, orphaned PVCs, and abandoned namespaces from feature branches that got merged months ago.
The actionable work in cost analysis is separating these two categories before acting on either. Start by looking at actual CPU and memory utilization for each workload over a representative time window, usually at least two weeks, ideally four.
Workloads where actual utilization is consistently below 30% of requested resources are candidates for right-sizing. Workloads where utilization is spiky or hard to predict need a different approach, typically involving autoscaler tuning rather than simple request reduction.
There is no shortage of blog posts about theoretical Kubernetes cost optimization. This section focuses on the methods that have a meaningful impact in real-world enterprise environments, ranked roughly by impact-to-effort ratio.
This is consistently the highest-leverage optimization available, and consistently the most under-executed. Resource requests in Kubernetes determine how the scheduler places your pods and how the Cluster Autoscaler decides when to add or remove nodes.
Requests that are too high cause the cluster to provision more nodes than workloads actually need, which is the primary source of the 30–60% allocation waste figure cited earlier.
Requests that are too low cause instability: OOMKills, CPU throttling, and degraded performance under load.
The right approach to right-sizing is empirical, not intuitive. You look at actual utilization data for each container over a representative window, identify the P90 or P95 utilization value, and set requests at or slightly above that level.
Limits can be set higher to give headroom for spikes, but they should not be unbounded. Unbounded CPU limits are a common cause of noisy neighbor problems on shared node pools.
For memory specifically, it is generally safer to set limits closer to requests. A container that hits its memory limit gets OOMKilled, which is a visible and diagnosable event, rather than silently degrading the way CPU throttling does.
Doing this at scale across hundreds of microservices, maintained over time as workloads change, is where the effort multiplies quickly. This is the kind of ongoing operational work that tends to get deferred in favor of feature delivery, which is exactly how a well-tuned cluster from six months ago becomes an expensive cluster today.
GKE gives you three autoscaling dimensions: Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), and Cluster Autoscaler.
Used well together, they eliminate a significant portion of manual right-sizing work. Used without coordination, they can work against each other in ways that are genuinely confusing to debug.
Use HPA when your workload is stateless, can scale horizontally without coordination overhead, and has load patterns that are predictable enough to drive a metric-based scaling policy. Web services, API gateways, and queue consumers are typical candidates.
The common misconfiguration here is setting the CPU target too low. A 50% CPU target sounds conservative, but on a workload with a significant idle baseline cost means you are continuously running twice as many replicas as you need at off-peak hours.
Use VPA when your workload cannot easily scale horizontally, like stateful services, batch jobs, and workloads where adding replicas has diminishing returns.
VPA adjusts resource requests based on observed usage, but requires a pod restart to apply new values, which means it is not a zero-disruption optimization for production workloads during business hours.
Most teams configure VPA in recommendation-only mode for production services, using it to surface right-sizing opportunities that get applied during maintenance windows.
Use both HPA and VPA when you have workloads that need horizontal elasticity and periodic right-sizing of baseline requests.
The important constraint is that HPA and VPA should not both target the CPU on the same workload. This creates a conflict where HPA scales up replicas while VPA simultaneously tries to reduce per-pod resource requests, and the two systems fight each other in a way that produces neither cost savings nor stability. Use HPA on CPU, and let VPA handle memory right-sizing on the same workload if needed.
Cluster Autoscaler operates at the node level and is mostly responsible for translating pod-level scaling decisions into node provisioning.
Scale-down is the part that tends to be undertuned. The default settings are conservative, which means nodes added during a traffic spike often stay around longer than necessary.
Reviewing your scale-down utilization threshold (default 0.5) and delay settings is a low-effort way to recover consistent cost savings on variable workloads.
Not all workloads need the same grade of compute, and running everything on standard on-demand instances is a safe default that is also an expensive one.
Google Cloud’s Spot VMs offer discounts of 60 to 91% compared to on-demand pricing, with the trade-off that they can be preempted with a 30-second warning.
The practical strategy for most enterprise environments is a tiered node pool approach: a baseline of on-demand nodes for latency-sensitive, stateful, or SLO-critical workloads, and a separate Spot node pool for batch processing, CI/CD workloads, non-production environments, and stateless services that can recover from preemption gracefully.
Kubernetes node affinity and tolerations make it straightforward to control which workloads land on which pool. The key engineering investment is ensuring that Spot-eligible workloads are actually designed to handle preemption like graceful shutdown handling, retry logic, and checkpoint mechanisms where the job duration warrants it.
Committed Use Discounts (CUDs) are worth evaluating separately for your on-demand baseline. If you have a stable minimum compute floor, meaning workloads that run continuously regardless of traffic patterns, committing to that baseline with 1-year or 3-year CUDs can reduce those costs by 20 to 55% compared to on-demand pricing.
The analysis is simply identifying the lowest point of your compute utilization over a rolling six-month period and treating that as a safe commitment floor.
Persistent Volume Claims are one of the quieter sources of GKE cost waste, largely because they persist after pods are deleted unless explicitly removed.
Every development environment, feature branch deployment, and abandoned namespace that used persistent storage is still generating a storage bill until someone manually cleans it up.
A periodic audit of unbound PVCs is a simple way to identify and recover these costs, and is worth building into a regular operational cadence rather than treating it as a one-off task.
Traffic between zones within the same region incurs charges, traffic between regions incurs higher charges, and traffic leaving Google’s network entirely is the most expensive category.
For microservice architectures, mapping your service communication patterns and identifying inter-zone or inter-region traffic that could be reduced through topology-aware routing is a meaningful cost lever.
Kubernetes topology spread constraints, and service topology features can help keep traffic within a zone where possible, and are worth evaluating if your architecture involves services that are heavily chatty across zone boundaries.
At a certain scale, manual cost management becomes untenable. You cannot realistically review resource requests for 400 microservices every sprint cycle, monitor utilization trends across a dozen namespaces, and keep your autoscaler configuration synchronized with changing traffic patterns, while also handling everything else an SRE or platform team is responsible for.
This is where cost optimization algorithms and automation become necessary rather than optional.
The core logic of any cost-optimization algorithm in Kubernetes is typically: observe actual utilization, compare it with requested resources, and produce a recommendation for right-sizing that balances cost reduction with risk.
Simple implementations take a percentile of observed CPU and memory utilization and recommend setting requests to that value. More sophisticated implementations model utilization patterns over time, account for workload seasonality (business-hours spikes, end-of-month batch jobs, weekly traffic patterns), and incorporate risk signals like recent OOMKills or HPA scaling events before making any recommendation.
The total cost of optimization, accounting for both infrastructure spend and the engineering time required to implement and maintain it, needs to factor in how much human review and intervention the approach requires.
An algorithm that generates 200 recommendations per week and requires manual review of each one has a very different effective cost than one that identifies and applies safe changes automatically with an audit log and rollback capability.
At scale, the operational overhead of the optimization process itself is a real cost that tends to be underweighted in FinOps conversations.
Automated right-sizing is most appropriate for workloads where utilization patterns are stable and well-understood, the business impact of a brief disruption is low (non-production environments, background jobs), and the team has confidence in the observability data feeding the algorithm.
Production, customer-facing services with strict SLOs are better served by recommendation workflows, where automation surfaces the opportunity and a human approves and schedules the change, rather than a fully autonomous application.
The practical starting point for most teams is to automate right-sizing for non-production environments completely and apply a recommendation workflow for production.
This alone can surface significant savings with a low risk profile, and as confidence in the automation builds, the scope of automated applications can expand accordingly.
It is also worth being clear that optimization is a continuous operational responsibility. The average enterprise GKE cluster changes significantly every quarter: new services get deployed, existing services grow, and traffic patterns shift. Right-sizing work done in Q1 is partially obsolete by Q2, and largely irrelevant by Q4.
For organizations with large engineering orgs and limited platform team bandwidth, automation is the only approach that keeps pace with the rate of change without requiring proportional headcount growth.
Cost data that only lives in the platform team’s dashboard does limited work. The organizational mechanism that makes GKE cost optimization self-sustaining is making costs clearly visible to the teams that generate them, because when development teams have no visibility into the cost of their workloads, there is no natural feedback loop.
Teams provision what they need, the platform team absorbs the cost, and nobody has an incentive to optimize because nobody feels the consequences of not optimizing.
A practical cost allocation model for GKE starts with consistent labeling. Every workload should carry labels that identify its owning team, its environment, and its application or service name.
With consistent labels in place, GKE cost allocation and BigQuery billing exports can attribute costs to those dimensions accurately, and the attribution holds up through infrastructure changes as long as the labeling convention is maintained.
The next step is making those attributed costs visible to the teams that own them. This might mean a weekly cost report sent to team leads, a cost dashboard embedded in your internal developer portal, or a Slack notification when a team’s namespace cost crosses a threshold.
The people who make decisions about workload configuration should have timely, accurate feedback about the cost implications of those decisions.
Chargeback models where team budgets are actually debited based on cloud spend are more effective than showback models at driving behavioral change, but they require more organizational infrastructure to implement fairly and consistently.
Most platform teams arrive at the same point after working through the strategies above. The analysis is clear, the recommendations are reasonable, and the implementation and ongoing maintenance are the parts that are hard to sustain alongside everything else the team owns.
Cost allocation, right-sizing, autoscaler tuning, and anomaly detection are tractable problems in isolation, but keeping all of them current as the cluster evolves is where the operational load accumulates. That is the gap Komodor is designed to close.
Komodor’s AI SRE platform continuously monitors workload utilization across your GKE clusters, identifies right-sizing opportunities, surfaces cost anomalies before they compound, and attributes spend to the teams and services that generate it.
The platform’s autonomous capabilities mean that safe, well-understood optimizations can be applied automatically, while changes with higher risk profiles go through a review workflow, so your team spends its time on decisions that require human judgment, not on triaging a growing spreadsheet of recommendations.
For enterprises managing GKE at scale, the question is whether to optimize costs manually, at the pace your team can sustain, or to put automation behind it so the work keeps pace with your infrastructure’s rate of change.
If you want to see how this applies to your specific environment, the Komodor team is ready to walk through your GKE setup and show you what the platform surfaces.
The range is wide, but most enterprise Kubernetes environments have 30% to 60% of their compute resources allocated but not actively used.
Practical savings from a structured optimization effort like right-sizing, autoscaler tuning, and Spot VM adoption for appropriate workloads typically fall between 25% and 45% of total GKE compute spend, depending on the starting configuration.
The exact figure depends heavily on how well-tuned the cluster was before the optimization effort and how much of the workload is compatible with Spot VMs.
Start with your actual resource utilization for each workload compared to your current resource requests.
The gap between requested and actual utilization represents allocation waste. Multiply that by your per-node cost and the proportion of time the cluster is over-provisioned to get an estimate of recoverable spend.
Add to that any costs associated with idle or abandoned resources like unbound PVCs, development environment clusters left running, and Spot-eligible workloads currently on on-demand compute.
GKE cost allocation is a billing feature that attributes Kubernetes resource costs to the namespaces and labels of the workloads consuming them. It matters because without it, your cloud bill tells you what you spent but not who spent it or why.
With cost allocation enabled and a consistent labeling strategy in place, you can charge costs back to teams, identify the highest-spend services, and have data-backed conversations about where optimization effort should be prioritized.
A practical monitoring stack combines GKE cost allocation in Google Cloud Billing, export to BigQuery for queryable historical data, and a dashboard layer, either Looker Studio, Grafana with a BigQuery data source, or a purpose-built platform.
Google Cloud’s built-in budget alerts are a useful complement to threshold-based notifications. For teams that want tighter integration with Kubernetes-native data, tools that pull both billing data and cluster utilization metrics together give a more complete picture than billing data alone.
Use HPA for stateless, horizontally scalable workloads with predictable load patterns like web services, API gateways, and queue consumers.
Use VPA for workloads that cannot scale horizontally, or where per-pod resource right-sizing is the primary lever, like batch jobs, stateful services, and workloads with stable but over-provisioned baselines.
Avoid targeting the same resource metric with both HPA and VPA on the same workload, as this creates a conflict between the two controllers that tends to produce unstable and expensive behavior.
The Cluster Autoscaler adds nodes when pods cannot be scheduled due to resource constraints, and removes nodes when their utilization falls below a configurable threshold.
Costs increase when the autoscaler adds nodes that stay provisioned longer than necessary, which happens when scale-down settings are too conservative or when workloads hold resources after they are done with them.
Tuning the scale-down utilization threshold (default 0.5) and delay settings, and ensuring workloads release resources promptly when they finish, can meaningfully reduce average node count over time.
Cost is minimized when resource requests match actual utilization as closely as possible, workloads that tolerate preemption run on Spot VMs, the Cluster Autoscaler removes underutilized nodes promptly, and there are no significant orphaned resources consuming budget without serving active workloads.
Getting to that state requires both the initial optimization work and ongoing tooling to detect and correct drift as the cluster changes over time, because a well-optimized cluster today is a partially-optimized cluster three months from now if nothing is actively maintaining it.
Share:
Gain instant visibility into your clusters and resolve issues faster.
May 12 · 9:00EST / 15:00 CET · Live & Online
🎯 8+ Sessions 🎙️ 10+ Speakers ⚡ 100% Free
By registering you agree to our Privacy Policy. No spam. Unsubscribe anytime.
Check your inbox for a confirmation. We'll send session links closer to May 12.
