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!
Part five of our Kubernetes and Cloud native application checklist evaluates cloud native storage tools based on ease of installation and continued operations in cloud native environments as well as the feature set provided.
June 15, 2020
4 min read
A comprehensive guide to managed Kubernetes distributions outlining the features that CIOs, CTOs and ITDMs need to consider when evaluating enterprise Kubernetes distributions.
June 8, 2020
4 min read
Cloud native has taken the IT landscape by storm. But what is it? We sat down with Pini Reznik, CTO at Container Solutions and co-author of “Cloud Native Transformation: Practical Patterns for Innovation” to try and figure out what exactly Cloud native is, which specific technology pieces, processes and cultural dynamics need to come together to create Cloud native environments and the best way for organisations to forge into the Cloud native future.
April 22, 2020
4 min read