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:
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.
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.
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.
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.
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.
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
Fan of all things cloud, containers and micro-services!
Kubernetes Operators are built for specific applications and make it easier to create, configure, manage and operate those applications on Kubernetes. In this blog post we dig into the mechanics of Kubernetes operators and outline 5 operators that every DevOps needs to know about.
February 17, 2020
4 min read
Part Two of our Kubernetes and Cloud native application checklist outlines CICD tools that CIOs, CTOs and DevOps teams leads can use to accelerate the build, test and deploy workflow for cloud native containerised applications.
January 27, 2020
4 min read
Part One of our Kubernetes and Cloud native application checklist outlines the tools and applications that CIOs, CTOs and DevOps teams leads can use to de clutter the development workflow making it easier for developers to write code and reduce integration issues when going to production.
January 20, 2020
4 min read