NOTE: This launch happened on July 3, 2023. The new weighting system is now in place. For any backfill prior to this date please reach out to your TAM or Apptio support.

We're excited to announce an enhancement to the cost allocation logic for our container insights. These insights will use a dynamic weighting for CPU, memory, and local storage for nodes in your clusters. In simple terms, VMs which have an emphasis on CPU will have a higher CPU cost weighting, while VMs focused on memory will have a higher memory cost weighting. For you, this improves how costs are allocated to individual Namespaces and Labels, better matching how the underlying Virtual Machines are charged by the cloud vendors. This change will be in effect for all cloud vendors (AWS, Azure, and GCP) and node types starting July 1 (see further below for rollout plan)

What is “resource weighting”

While it’s relatively straightforward to calculate the cost of each K8s cluster – by mapping the underlying VMs and disks – additional work is required to break each VM/disk up so they can be allocated out (there is no information within vendor billing files to help do this). Identifying what resources (CPU, Memory, Network etc.) are being consumed across Namespaces or labels, it is then key to be able to tie a cost contribution to these resources. This is where resource weighting comes in.

When we say CPU weight or memory weight, what we’re talking about is the percent of the total node (i.e., VM) cost that should be associated to CPU or memory usage. When we first launched our container cost allocation capability this was based on standard weightings that were used across all VM types. While this generally worked well, it has become clear that the wide variety of node types in use has necessitated a more nuanced approach. 

New VM family-based weightings

The goal of the new VM weighting system is to best match how each of the vendors tie cost to CPU, memory, disk and network - this can be established by comparing the prices and amount of each resource between two families. Let’s look at how we do this starting with disk and network.

Disk and Network

For VM families that don’t have local storage, this is simple, the cost contribution is zero %. For families that do have local storage we calculate the impact of that storage. For example, looking at AWS EC2, the m5.xlarge and m5d.xlarge VM types have exactly the same vCPU and memory, with only m5d having local storage. With the m5.xlarge costing $0.192 per hour and the m5d.xlarge $0.226 per hour, we can say this additional $.034 charge for storage makes up 15% of the total m5d.xlarge cost.

For network charges, since this isn’t VM specific and normally is a lesser factor, we’ve associated a standard 5% cost for all VM types. The remainder of the VM cost is therefore split between memory and CPU, which for m5.xlarge would constitute 95% and for m5d.xlarge 80%.

Memory and CPU

To split this remaining cost, we can do a similar - albeit more complex - comparison between VM families to work out the cost per vCPU and GB of memory. For any VM we could say:

VM hourly rate = vCPU count * vCPU rate + memory * memory rate

If we can work out the vCPU rate and the memory rate, then it’s possible to establish the ratio (i.e., weightings) for any VM family. While there are two unknown variables (the rates), we can solve these by having two separate equations – one for the target VM family and one for a “base” VM family.

It is worth discussing briefly how a base VM family is picked. The first thing to note is that the base VM will belong to the same processor manufacturer, whether that is AMD, Intel, or graviton. We will also prioritize a VM family from the same generation. For example, if the target is c6i, the base VM family used will likely be either m6i or r6i.

Having resolved the vCPU rate and memory rate for each VM family it is straightforward to calculate the weightings – multiplying the amount of vCPU and memory by their rates, then establishing the ratio between CPU and memory cost. Note, due to how the vendors bill their VMs, that these ratios are consistent at the family level.

What does that mean for my cost allocation?

Here as some things to keep in mind:

·      There is no impact for cluster level cost figures. This change only applies to Namespaces and Labels

·      The standard weightings used previously skewed allocation towards memory usage. With this release it is now completely dependent on how the vendor charges for the specific VM family, but overall, this has shifted the weightings back towards CPU usage.

·      This change has been made to both the values found in the Container Cost Allocation feature and to the Namespace and label dimensions within core reporting.

·      This enhancement applies to both Kubernetes and ROSA clusters

Rollout Plan

This update will be launched on July 3 and apply to data from July 1, 2023 onwards. If your organization would like these new weightings backfilled to historical data, please reach out to your TAM or Apptio support. Stay tuned here to the Apptio Community as we launch this and further container enhancements.