Kubernetes solved a coordination problem for engineering teams. It abstracts away infrastructure, makes intelligent scheduling decisions, and scales horizontally, all by itself. For developers, this reduces friction; for platform teams, it simplifies deployment; and for finance teams, it creates a structural visibility issue.
The initial offering from cloud providers of billing models was for simpler resources like instances, volumes, and reserved instances. These resources are fairly long-lived, easily labelled, and are individually owned. Kubernetes changes the unit of abstraction; we now talk in pods, namespaces, and deployments, but your cloud provider will charge you per node, per network, and per persistent storage.
As adoption of the Kubernetes stack has become mainstream, what we see is the vast majority of organisations using cloud-native technologies in production. That’s where the disconnect goes from being an edge case to a systematic issue.
Ephemeral containers and broken tagging assumptions
Historically, cloud cost allocation was solved by tagging. Someone would provision an instance, annotate it with metadata for the environment or cost center, and the billing report would aggregate costs accordingly. This can only work if resources are long lived and able to be tagged and audited. In containers, that’s just not what happens. What you typically see is pods existing for a few minutes, CI pipelines spinning up preview environments, and HPAs scaling up or down based on request volume.
According to Kubernetes’ own resource management model, scheduling is based on CPU and Memory requests, not cost centers. If you scale up and a new node gets provisioned for 20 minutes, the cost report won’t show any changes on the node level, because the node won’t exist anymore by the time the report is generated. Tagging at the infrastructure layer cannot reliably map ephemeral workload behaviour to cost attribution. This is the point where conventional logic starts to break down.
Shared clusters and pooled infrastructure
Most teams use shared clusters since it’s a great way to get better utilization across multiple teams, and while that’s for engineering, it’s terrible for cost allocation. Multiple namespaces run on the same nodes, network egress costs are incurred at a VPC or project level, and storage classes hide the underlying volume. When the cluster autoscaler scales up, it does so in response to requested resources, not in response to a particular service.
So while a chargeback model implies ownership of a distinct asset, in a shared cluster, those assets are pooled. Determining what application caused the cluster to scale out is a question of correlating application-level instrumentation to infrastructure-level billing data. Without that correlation, the cost is a shared overhead, rather than an allocated responsibility. That is why FinOps must be done at the workload level, not just the infrastructure level.
Workload-level cost allocation
The FinOps Foundation's mission states that cloud cost management is a cross-functional discipline where everyone in the organization has a role to play in managing costs. In a Kubernetes context, that means allocating costs at the workload layer.
Unlike a per-VM cost model, mature organisations allocate to namespaces, services, or teams by merging cloud billing exports with Kubernetes usage records and allocating node, storage, and network costs based on actual or requested usage. Kubecost documents this approach extensively. When costs are mapped to abstractions that are relevant to engineers, there’s more of a sense of ownership.
The cost of a production namespace can be compared with the cost of its staging environment, and the cost of a cluster can be compared before and after a new deployment. This cost transparency helps turn a finance concept into an ops metric. The goal is not control, but informed ownership.
Rightsizing in a request-driven scheduler
Resource requests influence Kubernetes scheduling decisions. If you declare that a container requires 2 CPUs as part of a request field, then the scheduler will reserve that amount of capacity to the pod even if the workload doesn’t utilise it consistently. Over-estimating resource requests leads to bad bin-packing and autoscaling decisions. The consequence of fat-fingered requests is that it makes scale-out more likely. New nodes will be provisioned and billed even if they are not fully utilised.
Rightsizing in the context of Kubernetes means adjusting requests and limits so that the requested amount of resources matches the actual consumption profile. The process is simple: use historical usage data to make more informed assumptions about resource requests. The AWS Well-Architected Framework’s cost optimization guidance reiterates the same principle at the infrastructure level, while in Kubernetes, that tuning occurs at the container spec level.
With rightsizing, it’s equally important not to overcorrect. If you’re too aggressive, you’ll cause throttling or reduced performance if your workload experiences a sudden spike in traffic. FinOps is about efficiency, not recklessness.
Gaining visibility without losing velocity
The worry here is that more robust cost management will constrain developer velocity. One of the reasons for Kubernetes’ runaway success is that it removed the need for a central authority to provision infrastructure. Reintroducing centralised approval gates would undermine that. Instead, you give developers the data they need to make informed choices.
As opposed to introducing restrictive controls, cost-conscious organisations simply empower teams with more data. This could be via cost reports that aggregate spend at a namespace level, plan budgets at a team level, or assign lower resource defaults. For example, it may make sense to introduce automated shutdowns or lower default requests in dev environments. All these techniques allow innovation to continue while also avoiding waste.
From infrastructure billing to workload economics
Remember, Kubernetes doesn’t inherently increase cloud costs, what it does change is the visibility model. Billing is still infrastructure-centric, while operations are workload-centric. And so bridging that visibility gap requires new allocation models, disciplined rightsizing, and pervasive usage transparency.
As workloads become increasingly short-lived, event-driven, and elastic, fixed cost assumptions don’t hold. Ephemerality and shared infrastructure are the new normal.
Going forward, the organisations that manage their Kubernetes costs effectively are those that accept that and adjust their cost strategies accordingly. They stop allocating costs to VMs and start looking at the cost of their workload. Resource requests become a financial signal, and finance and engineering teams are aligned on shared metrics.
The challenge is to manage the cost implications of a perpetually changing workload without impairing the speed that Kubernetes enables and modern platforms demand.
