[Kubernetes, Kubernetes cost allocation, Kubernetes cost accounting]

3 Ways to do Cost Accounting and Allocation for Kubernetes Clusters

There are three ways organizations can do cost accounting and allocation for Kubernetes clusters: Based on Kubernetes primitives, based on infrastructure and based on custom organizational groupings. Read on to learn about each in more detail.

Hasham Haider

Hasham Haider

February 5, 2019

4 minute read

We have dived into Kubernetes cost accounting and why it is important in previous blog posts. In today’s post, we will discuss the different ways an enterprise can visualize costs and develop a cost accounting model for Kubernetes.

So let’s jump right into it.

Broadly speaking there are three ways enterprises can develop cost accounting models for Kubernetes:

  • Based on kubernetes primitives

  • Based on infrastructure

  • Based on custom organizational groups

Let’s analyze each of these categories in more detail:

Cost Accounting and Allocation Based on Kubernetes Primitives

Kubernetes has introduced a number of new concepts to the container space. These include pods, services, clusters, controllers and many more. Here we will focus on the ones that provide the most value in terms of cost accounting and allocation.

Book cover of 'Kubernetes Cost Analysis and Allocation on AWS' and button to download

We will start with Kubernetes itself. This might seem counterintuitive at first but it makes more sense once you consider the fact that enterprise Kubernetes workloads are more likely to be distributed across multiple cloud providers.

Having an overview of Kubernetes costs across all cloud providers is a good starting point. You can see this distinction in the screenshot below where Kubernetes costs are split between AWS and GCP. This cost distribution will automatically propagate to other cloud providers as and when the enterprise starts to leverage them.

Kubernetes cost accounting and allocation

Clusters are the next level of abstraction that we can track costs for. Clusters pool together resources from multiple cloud VM’s called nodes in the Kubernetes context. Visualizing costs on the cluster level can be very useful since that is the level of abstraction most DevsOps work with.

Next up are Kubernetes services. Kubernetes services group together a set of pods and define a policy by which they can be accessed. Tracking costs for service level abstractions can be useful since they give us the overall costs of a related set of pods.

Pods and containers are the next obvious choices. Pods are the smallest deployable unit in Kubernetes. Containers are the basic building blocks of containerized applications. Kubernetes allows us to allocate resources to containers using resource requests and limits. Since, resource usage is a big part of Kubernetes costs, tracking pod and container level costs can be very useful.

Cost Accounting and Allocation Based on Infrastructure

Another way of visualizing Kubernetes costs is to group or split them, based on the infrastructure layer. Infrastructure refers to the underlying cloud VMs and/or physical on-premise hardware that Kubernetes leverages resources from.

With the current trend of having hybrid or multi-cloud deployments, the infrastructure layer can have a pretty broad footprint, extending across multiple public cloud providers, on-premise data centres, private cloud setups or even edge infrastructure.

For such a broad infrastructure layout, it is useful to visualize Kubernetes costs based on where they are coming from. This would essentially mean having visibility into how Kubernetes costs are divided between the individual infrastructure variants.

But that is just the start. We can dig deeper and visualize costs for the individual VMs that run our Kubernetes workloads. This will give us more granular insight into how costs are driven by different VM variants both inside and across clouds.

Cost Accounting and Allocation Based on Custom Organizational Groupings

Kubernetes and infrastructure level cost accounting is useful and can give us insights into how these groupings contribute to costs.

Enterprises, however also need to track costs across a large number of custom groupings. A good example of this is tracking costs for individual teams and applications. Costs can also be tracked for departments, customers or projects, based on the requirements of individual environments.

By default, custom groupings tend to leverage resources from many different clusters. This can lead to a lot of overlap, where teams or applications leverage the same clusters, services or cloud VMs. Incorporating this overlapping usage will give us an accurate and reliable cost accounting model which can then be used to identify the teams or applications that drive most of our costs, the ones that use allocated resources optimally and where resources might be under-allocated.

Kubernetes cost accounting and allocation

Tracking Kubernetes costs for custom groupings like teams allow us to do chargeback and showback and also hold those teams accountable. We will also be able to quickly identify instances where resources are being wasted, make informed decisions about trimming or increasing the amount of allocated resources and implement cost management mechanisms. We can also identify trends in Kubernetes resource usage and plan ahead to expand or reduce our infrastructure footprint as demand varies.

Want to learn more? Download the Kubernetes cost accounting and allocation ebook for AWS


Hasham Haider


Hasham Haider

Fan of all things cloud, containers and micro-services!

Want to Dig Deeper and Understand How Different Teams or Applications are Driving Your Kubernetes Costs?

Request a quick 20 minute demo to see how you can seamlessly allocate Kubernetes costs to individual teams or applications while saving up to 30% on infrastructure costs using Replex.

Schedule a Meeting