India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Kubernetes FinOps: Namespace Cost Allocation and Request Rightsizing
Kubernetes FinOps is the practice of making shared container clusters financially accountable: allocating node, storage and network cost to namespaces, teams and workloads, then reducing waste by rightsizing pod requests, improving bin-packing and using Spot capacity. NTSPL delivers it on EKS, AKS and GKE using native cost allocation and OpenCost, without changing who runs the clusters day to day.
Delivered on
In scope
Where Money Disappears Inside Shared Kubernetes Clusters
Kubernetes hides cost in two layers. The cloud bill shows nodes, not workloads, so a ₹40 lakh-a-month cluster appears as one line owned by the platform team. Inside the cluster, developers set CPU and memory requests generously to avoid throttling and evictions, and the scheduler reserves capacity for those requests whether it is used or not. In clusters we review, requested CPU is typically 3-5 times actual p95 usage, and 35-55% of node capacity is either idle or reserved for requests that are never used.
NTSPL addresses both layers in order. First, cost is made visible per namespace and label using EKS split cost allocation data, the AKS cost analysis add-on, GKE cost allocation or OpenCost, with idle capacity reported separately. Then requests are rightsized from VPA recommendations and real usage, node pools are reshaped for bin-packing, and fault-tolerant workloads move to Spot. Teams see their own cost before they are asked to cut it.
Cluster Symptoms That Call for Kubernetes FinOps
Signals you need Kubernetes FinOps
- Kubernetes nodes are more than 25% of the cloud bill and appear as a single platform-team cost.
- Cluster CPU requests exceed 70% of allocatable capacity while actual usage sits under 30%.
- Product teams ask for more nodes, but nobody can say which namespaces consume them.
- All node pools run on-demand, including CI runners, batch jobs and stateless workers.
- Clusters run on GKE Autopilot or EKS Fargate, where you pay for requests, and requests have never been reviewed.
When to choose something else
- You need clusters upgraded, patched and supported around the clock: that is managed Kubernetes operations, not FinOps.
- Applications are not yet containerised or the platform is still being built: finish the platform work first.
- One small cluster runs a single product with one team: node rightsizing and a Savings Plan or CUD will capture most of the value.
Allocation and Efficiency Levers Inside the Cluster
Cost allocation by namespace and label
Node, persistent volume and load balancer cost allocated by requests or usage per namespace, team label and workload, with idle capacity shown separately.
Request and limit rightsizing
CPU and memory requests reset from VPA recommendations and p95 usage, with memory limits kept to prevent noisy-neighbour issues.
Bin-packing and node shapes
Node pool instance types, autoscaler profiles and consolidation settings adjusted so pods pack densely without fragmentation.
Spot and interruptible node pools
Stateless, batch and CI workloads moved to Spot node pools with disruption budgets and fallback to on-demand.
Non-production cluster efficiency
Dev and QA clusters consolidated, namespace quotas set, and idle namespaces scaled down.
How Kubernetes FinOps Works, Step by Step
Namespace Allocation and Request Rightsizing Loop
Cluster cost data from native allocation features or OpenCost is joined with namespace labels to produce team-level showback, including idle cost. Usage metrics feed request recommendations, which are applied through GitOps, while node strategy changes improve packing and move tolerant workloads to Spot.
Select any component
Namespace Allocation and Request Rightsizing Loop: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Kubernetes Cost Tooling on EKS, AKS and GKE
Split cost allocation data puts pod-level cost into CUR, so NTSPL allocates EKS cost in the same pipeline as the rest of the AWS bill rather than in a separate tool.
The AKS cost analysis add-on, built on OpenCost, shows namespace cost inside Cost Management; NTSPL pairs it with Spot node pools for batch workloads.
On Autopilot you pay for pod requests, so request rightsizing translates directly into billing savings; on Standard, savings appear only once nodes scale down.
Requests, Idle Cost and Node Strategy Choices
Allocate by requests or by usage
Allocate by the higher of requests and usage per pod. Requests are what the scheduler reserves and what blocks other pods, so allocating by usage alone rewards teams that over-request. Show cluster idle capacity as a separate line owned by the platform team, which keeps teams' numbers fair and gives the platform team a clear target for node strategy work.
Setting requests and limits
Set CPU requests near p95 usage and avoid CPU limits for latency-sensitive services, since throttling hurts more than sharing. Set memory requests near p99 and memory limits equal to or slightly above requests to prevent out-of-memory cascades. Use VPA recommendations, not automatic mode, for databases and stateful sets. Review JVM workloads separately because heap settings dominate memory behaviour.
Node pool shapes
Larger nodes reduce per-node overhead from system daemons, but too-large nodes fragment when pods are big. A useful rule: target nodes that fit 15-30 typical pods. Let Karpenter or node auto-provisioning choose from a list of instance types rather than fixing one. Keep separate pools only for distinct needs such as GPUs, Arm, Spot or compliance isolation.
What can run on Spot
Stateless services with three or more replicas, CI runners, batch and queue workers are good Spot candidates. Keep databases, single-replica services and anything with long graceful shutdown on on-demand. Diversify across at least four instance types and multiple zones. Spot interruption notice is two minutes on AWS and about 30 seconds on Azure and Google Cloud, so termination handling must suit the shorter window.
Visibility-First Kubernetes Cost Programme
Cost visibility
Native allocation or OpenCost enabled, namespace labels standardised, and first team showback with idle cost published.
Efficiency baseline
Request-to-usage ratios per namespace measured; VPA deployed in recommendation mode.
Request rightsizing waves
Pull requests raised per team for request changes, applied in waves with latency and eviction monitoring.
Node strategy changes
Consolidating autoscaler, node shapes and Spot pools introduced cluster by cluster.
Guardrails and handover
Admission policies, quotas and monthly efficiency reviews handed to platform and FinOps leads.
What you receive
Cluster Efficiency and Allocation KPIs
| KPI | Typical target |
|---|---|
| Cluster cost reduction | 25-45% |
| CPU request-to-usage ratio | From 3-5x to 1.3-1.6x |
| Cluster idle cost share | Below 20% of node cost |
| Spend allocated to a namespace owner | Above 90% |
| Out-of-memory kills after rightsizing | No increase versus baseline |
Cost Cuts That Break Kubernetes Workloads
| Risk | How NTSPL prevents it |
|---|---|
| Aggressive request cuts cause OOM kills or CPU throttling at peak. | Memory set at p99 with headroom, CPU limits avoided for latency paths, and changes applied in waves with rollback. |
| Spot interruptions during peak cause capacity shortfalls. | Instance diversification, PodDisruptionBudgets and automatic on-demand fallback configured before migration. |
| Teams dispute namespace costs because idle capacity is spread onto them. | Idle cost is reported separately and owned by the platform team, not allocated to product teams. |
Kubernetes FinOps or managed Kubernetes operations: which do we need?
Managed Kubernetes operations keeps clusters healthy: upgrades, node patching, add-on management and incident response under an SLA. Kubernetes FinOps makes them economical and accountable: who pays for what, whether requests are realistic, how densely pods pack and what can run on Spot. A well-operated cluster can still waste 40% of its nodes; a cost-optimised cluster can still fall behind on upgrades. If clusters are stable but expensive, start with FinOps. If upgrades and incidents are the pain, start with operations, then add FinOps once the platform is steady.
Key facts: Kubernetes FinOps
Kubernetes FinOps in Practice
2 Kubernetes FinOps scenarios, from Automotive connected-car platform (telematics, OTA updates and app backend) and Logistics (express parcel and e-commerce last-mile delivery), plus related platform case studies.
Connected-car platform cuts AKS node cost 38% and shows six teams their own spend
Express logistics firm halves GKE idle capacity and moves route planning to Spot
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
Kubernetes FinOps: Frequently Asked Questions
How long does Kubernetes FinOps take and what does it cost?
A first programme takes 12-14 weeks across three to six clusters. Visibility is in place by week three, with savings from request rightsizing and node strategy following. NTSPL prices it as a fixed fee per cluster group; native allocation features and OpenCost carry no licence cost.
Do we need a commercial Kubernetes cost tool?
Not necessarily. EKS split cost allocation data, the AKS cost analysis add-on and GKE cost allocation cover most single-cloud needs, and OpenCost provides consistent allocation across providers. Commercial tools add features such as automated recommendations and governance workflows, worth evaluating for large multi-cluster estates.
Will request rightsizing affect application performance?
Not if done carefully. NTSPL sets memory from p99 usage with headroom, avoids CPU limits on latency-sensitive services, and applies changes in waves while watching latency, throttling and OOM events. Any regression rolls back through the same GitOps pull request.
How should shared cluster cost be split across teams?
Allocate each namespace the higher of its requests and its usage, priced at actual node cost including commitments. Report idle capacity separately under the platform team. This rewards teams for realistic requests and gives the platform team ownership of packing efficiency.
Can Kubernetes cost data stay in India?
Yes. Native allocation data lands in your billing export or Cost Management, which you can keep in AWS Mumbai, Azure Central India or Google Cloud Mumbai or Delhi datasets. OpenCost runs inside your cluster and stores data in your own Prometheus, so nothing leaves your environment.
How do Spot node pools work with Savings Plans or CUDs?
Spot usage cannot be covered by commitments. NTSPL commits only to the steady on-demand floor that remains after Spot adoption and rightsizing, recalculated once the new node mix has run for a month, so commitments are not stranded by the shift.