This article is from Rancher Labs
Pay attention to us, the first time to obtain technical dry goods
The complexity of calculating Kubernetes costs
The adoption of Kubernetes and a service-based architecture offers many benefits to the enterprise, such as faster team migration and easier application scaling. But the shift also brings some complications, such as the visibility of cloud costs. This is because applications and their resource requirements often change dynamically, and teams share core resources without a transparent price tied to the workload. In addition, enterprises that are fully aware of the advantages Kubernetes offers will often run their resources on different types of machines, or even on multiple cloud providers.
In this article, we’ll look at best practices and different implementations of cost monitoring for Showback/Chargeback projects in the enterprise, and how to empower users to act on this information. We’ll start with Kubecost, which provides an open source way to ensure consistent and accurate visibility across all Kubernetes workloads.
Let’s take a closer look at best practices to accurately allocate and monitor Kubernetes workload costs and expenditures on associated hosting services.
Cost allocation
Allocating resource costs accurately is the first step to creating cost visibility and efficient cost utilization in the Kubernetes environment.
To do this correctly, you need to allocate costs across individual containers at the workload level. Once workload allocation is complete, costs can be correctly allocated to teams, departments, and even individual developers by aggregating different sets of workloads. The cost allocation framework at the workload level is as follows:
Let’s break down the framework bit by bit.
The average amount of resource consumption is calculated by the Kubernetes Scheduler or provided by the cloud provider, depending on the specific resource being measured. We recommend that memory and CPU allocations be calculated based on the maximum request and usage values. This reflects the amount of resources reserved by the Kubernetes Scheduler itself. On the other hand, resources such as load balancers and persistent volumes are strictly based on the number provided by the provider.
The Kubernetes API can directly calculate the time period of resource consumption. This is determined by the amount of time resources (such as memory, CPU, GPU, etc.) are consumed in the Running state. To make the data precise enough for cloud ChargeBack, we recommend that the team reconcile the data with the time spent on specific cloud resources (such as nodes) provided by the cloud provider. We’ll talk more about this in a later section.
Resource prices are determined by looking at the cost of each particular resource in the environment. For example, the CPU hour price of an m5.xlarge Spot instance in the US-East-1 AWS region is different from the on-demand price of the same instance.
Using this framework, costs can be apportioned appropriately between workloads so that they can be easily aggregated through any Kubernetes concept, such as namespaces, labels, annotations, or controllers.
Kubernetes cost monitoring
With costs assigned by Kubernetes concepts such as POD or Controller, you can begin to accurately map expenses to any internal business hierarchy, such as team, product, department, or cost center. A common practice for enterprises is to partition team workloads through the Kubernetes namespace, while other practices may use Kubernetes tags or annotations to identify which team the workload belongs to.
Another key element in cost monitoring across different applications, teams, and so on is determining who should pay for unused capacity. Specifically, it refers to the unused cluster resources that are still being billed to the enterprise. Typically, these costs are either accounted for in a central infrastructure cost center or distributed to application teams on a pro rata basis. Allocating these costs to the team responsible for supply decisions can have a positive effect by adjusting incentives to have an efficient scale cluster.
Check the cloud bill
Kubernetes provides a lot of real-time data. This gives developers direct access to cost metrics. While this real-time data is often accurate, it may not exactly match the billing data from the cloud provider. For example, when determining hourly rates for AWS SPOT nodes, users need to wait for spot data sources or cost and usage reports to determine accurate rates. For billing and charging purposes, you should check the data against the actual bill.
Get better visibility and governance with Kubecost
We’ve seen how to look at the data to calculate the cost of the Kubernetes workload. Another approach is to leverage Kubecost, a cost and capacity management solution built on an open source basis that provides visibility into the entire Kubernetes environment. Kubecost provides cost visibility and insight into Kubernetes workloads and the related management services (such as S3 or RDS) they consume. The product collects real-time data from Kubernetes and can also be checked against your cloud billing data to reflect the actual price you’re paying.
With solutions like Kubecost, you can empower application engineers to make informed real-time decisions and start implementing both immediate and long-term practices to optimize and govern cloud spending. This includes cost optimization without compromising performance, implementing Kubernetes budgeting and alerting, Showback/Chargeback projects, and even cost-based automation.
Kubecost Community Edition is free to use and has all of the above features. You can find Kubecost Helm Chart in the Rancher app store for easy deployment. With Rancher, you can get the Kubernetes cluster visualization and great control experience, while Kubecost provides you with a direct look at spending and how to optimize costs. Together, they provide a complete cost management solution for teams using Kubernetes.