Container Cost Management: Allocating Kubernetes Costs The Easy Way

Containers are one of the most popular ways for businesses to deploy applications. They provide an easy method of packaging applications into self-sufficient units that can be used, moved around, and re-used in any number of ways without breaking the overall functionality of your software.

With the possible exception of serverless architecture, containerization is perhaps the best way to achieve smooth, seamless application deployment and minimal hassle with updates and application maintenance.

However, one of the drawbacks of a container orchestration system like Kubernetes is that it obscures your view into the true costs of each of your services. The extra layer between you and your costs makes developing an effective container management strategy even more difficult than it is with straightforward, un-containerized cloud services.

Below, we’ll explore how to manage container costs in an ideal scenario where costs are perfectly accessible, explain why this ideal scenario simply isn’t possible for most companies, and suggest realistic actions you can take to implement an effective Kubernetes cost allocation strategy for your business.

Use This Container Management Guide To Allocate Your Kubernetes Costs

In an ideal world, here’s what to do

The main sources of your costs are the EC2 machines (or comparable cloud computing VMs such as GCE instances) that your services require to run. Kubernetes usually decides when and how many nodes to run at a time, so, in theory, all you have to do is break things down and assign the costs of those machines to your individual services.

Let’s say, for example, that your Kubernetes cluster’s autoscaler ran a given EC2 instance for one hour. If that machine has two CPUs and eight gigabytes of RAM, those resources are available for your workloads to use.

It won’t impact your bill if you use them at full capacity or leave them sitting idle. What you actually pay for is an hour of that EC2 instance, regardless of what happens during that time.

The workloads you run use measurable amounts of compute and memory, even if you pay for the time rather than the resources used. To find a link between these mismatched data sets, you need to figure out how to use those memory and compute measurements to map part of the instance’s cost to individual workloads or services.

The best way to accomplish this will depend on the specifics of your workload. It may be difficult, but aim to assign some part of the instance’s price to memory, and the rest to compute.

Once you have the individual costs assigned, you can then use these numbers to draw any sort of correlations you see fit and use that context to inform your future business decisions.

It’s possible, if a little tricky, to attribute certain costs to specific engineering choices. With all the costs laid out, engineers will be able to see why one service costs far more than another comparable service, even if these services are running within a container orchestration system like Kubernetes.

When it comes time to design the next application, engineers can go into it with a strategy for cost efficiency based around the insights gained from their container cost analysis.

The trouble with gaining true cost visibility

With traditional, non-containerized development, you can often (with some degree of effort) itemize the costs of certain items, projects, and teams, by efficiently managing your tags and tracking expenses under each category.

Serverless spending, too, can be relatively easy to track, because serverless services charge based on usage. You can simply map individual functions, managed database tables, message queues, and so forth to their relevant stakeholders. The price correlates directly with the workload, and both are obvious in your reports.

However, when you have multiple products or applications, each with its own series of containerized services running multiple types of pods with unique resource requirements and scaling behaviors, it becomes nearly impossible to assign those costs back to the projects and teams responsible for them.

As you deploy an application, what you’re spending money on are the resources needed to perform all the functions of that application. You will, for example, be paying for the number of EC2 nodes required to perform the workload of your application.

Kubernetes often chooses the number of resources required behind the scenes. To make matters more complicated, the combination of workloads running on any given machine is dynamic and the actual scaling behaviors are a result of complex decisions made by the cluster. Therefore, they won’t be the same from one instance to the next.

This automated scaling and management of your clusters and nodes, while extremely convenient and time-saving, takes the choices of which resources to consume and when out of your hands. At the end of the day, you have no direct control over your costs or insight into why your costs turned out the way that they did.

You’ll have a general understanding that the number of instances you’re running is likely appropriate for the actual workload that is being processed, but there’s no guarantee your workload is reasonable.

Beyond that, you’ll have no explanation of which tasks are driving the majority of your costs and which are not. When the costs of each task are all lumped together, there is no clear way to determine which pods are running more or less efficiently than others.

You also will have no way to see if the costly pods are providing enough value to be worthwhile in comparison to the less expensive pods. Ultimately, what you’re left with when it’s time to pay the bill is a whole bunch of information, including the number of pods that are running and how much money you owe, with no obvious link or correlation.

When most of the relevant information is hidden behind several layers of automation that remove you from control over the situation, it can be next to impossible to get an accurate big-picture view of your container costs. The information you need to gain real insight is packaged neatly into a little black box of obscurity.

The hard solution vs. the easy solution

You could build a proprietary program to handle Kubernetes cost allocation based on the exact services your business uses.

With a deep understanding of each service you offer, the resources needed to run those services, how containerization structures work, the Kubernetes containers that are running which applications, and the tagging scheme that will bring the most clarity to your container costs, it is possible to put together a platform that can give you real insights that you can use to guide future decisions.

If building your own solution sounds too complex, that’s because, for most companies, it is.

Realistically, it would take a dedicated team months or years to devise a workable platform, followed by ongoing maintenance and upkeep tasks that soak up enough time to become full-time jobs on their own.

Unless you’re prepared to essentially start a new department to build this bespoke container cost management platform, you’re better off not reinventing the wheel. The easier way is to allocate costs with a container cost management solution that takes care of the hard work for you.

CloudZero is a cost intelligence platform that can be used to simplify cloud cost management; it is particularly good at revealing the details usually hidden within Kubernetes containers.

On a minute-by-minute basis, the platform collects metrics about the resources the jobs in your cluster are using. When you look at your report, you’ll see the costs of your EC2 instances already broken out across your Kubernetes workloads by means of our custom pricing model.

Once you have access to your itemized costs, you’ll have a clear picture of your costs per pod, per namespace, or per any other groupings of your choice. From there, you can optimize as you see fit.

Instead of taking stabs in the dark, you’ll be able to easily answer questions like:

These are the types of insights that can help you make a real impact on your company’s container costs.

to see how CloudZero uncovers the data you need to efficiently manage your container costs.

Author: Cody Slingerland

Cody Slingerland, a FinOps certified practitioner, is an avid content creator with over 10 years of experience creating content for SaaS and technology companies. Cody collaborates with internal team members and subject matter experts to create expert-written content on the CloudZero blog.