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!
In this instalment of the Kubernetes in Production blog series, we take a deep dive into monitoring Kubernetes resource metrics. We will see why monitoring resources is important for Kubernetes in production, choosing which resource metrics to monitor, setting up the tools required including Metrics-Server and Prometheus and querying metrics.
March 7, 2019
4 min read
Deploying Kubernetes in production is no easy task. Kubernetes environments need to hold up on the rough seas of production from an availability, security, scalability, resilience, monitoring and resource management perspective. In this instalment of the Kubernetes Production Readiness and Best Practices Checklist series, we dive into the topic of Resource Management.
February 27, 2019
4 min read
This is the second instalment in our Kubernetes Labels and Label Selectors Best Practices blog series. In this article, we dive deeper into best practices for Label Selectors in the context of Kubernetes Controllers.
February 22, 2019
4 min read