Cutting Kubernetes costs – and cutting carbon
These are 10 strategies for reducing Kubernetes costs. We’ve split them into pre-deployment, post-deployment and ongoing cost optimisation techniques to help people at the beginning and middle of their cloud journeys, as well as those who have fully adopted cloud and are just looking for a few extra pointers.
At Turn It Off, we’re committed to helping the cloud industry become more sustainable – which we achieve through our AI-powered platform and by sharing a little knowledge on how to cut cloud costs, usage and carbon.
So, let’s get started.
10 Kubernetes cost optimisation strategies
Pre-deployment strategies
These pre-deployment strategies are for those just starting out.
Some will be more relevant to teams at the beginning of their cloud journeys; some will apply to those with an existing environment yet to deploy Kubernetes.
1. Pick a cloud provider – not cloud providers
Although multi-cloud architectures offer great flexibility in general, they can often incur a greater cost when it comes to Kubernetes. This is related to the different ways Kubernetes is provisioned.
On AWS, EKS is the primary way users access Kubernetes; on Azure, it’s AKS. Each is built on top of the core Kubernetes architecture and utilises it in different ways.
Each cloud provider has their implementations, extensions, best practices and unique features, which means what might work well for cost optimisation on EKS works less well (or simply isn’t an option) on AKS.
Add to this the operational cost of managing Kubernetes through multiple services and you begin to understand the cost optimisation issues presented by a multi-cloud environment.
So, in cost (and complexity) terms it’s better to choose a single provider.
2. Choose the right architecture
For those at the next step of their cloud and Kubernetes journey, cloud costs (along with everything else) will be significantly impacted by the type of architecture you choose.
And when it comes to Kubernetes, there are a few dos and don’ts.
As you’ll likely know, microservice-based architectures are a great fit if you’re using Kubernetes clusters or containers more generally. And monolithic applications will fail to leverage the full benefits of containerisation.
However, there are other considerations which aren’t as well known.
Stateful applications such as SQL databases aren’t a great fit for containers.
Likewise, applications which require custom hardware (like heavy-use AI/ML) aren’t ideal Kubernetes candidates either.
After you’ve picked your cloud provider, it’s best to consider the degree to which you’ll be adopting Kubernetes and containers and then make an informed choice about your architecture.
Post-deployment strategies
These strategies apply to those already using Kubernetes and looking for new methods to reach peak cost efficiency.
3. Set the right resource limits and quotas – alongside proper scaling methods
Resource limits and quotas put brakes on how you consume, without these any Kubernetes cluster can behave in unpredictable ways.
If you set no limit to any pod within a cluster, one pod could easily run away on memory and CPU.
For example, if you have a front-end pod, a spike in user traffic will mean a spike in consumption. And while you certainly don’t want your application to crash, unlimited resource consumption is not the answer.
Instead, you need sensible resource limits and other strategies for dealing with heavy usage.
In this case, optimising your application’s performance would be a better way of ensuring you meet customer demand without incurring extra costs.
The same is true of quotas, although these apply at the namespace level and to other types of resources.
In essence, it’s about setting limits based on what’s prudent, and ensuring you deliver by having other methods in place for scaling.
4. Set smart autoscaling rules
When it comes to auto-scaling in Kubernetes, you have two options: horizontal scaling and vertical scaling. You will determine which to do under what conditions using a rule-based system.
Horizontal scaling means increasing the total number of pods while vertical scaling means increasing pods’ memory and CPU capacity without increasing their total number.
Each method has its place when it comes to ideal resource usage and avoiding unnecessary costs.
Horizontal scaling is the better choice when you need to scale quickly. Also, because the more pods you have the less chance a single point of failure will result in a crash, horizontal scaling is preferable when distributing heavy traffic.
It’s also the better option when running stateless applications, as extra pods are better able to handle multiple concurrent requests.
Vertical scaling is more beneficial to stateful applications, as it’s easier to preserve a state by adding resources to a pod as opposed to spreading that state across new pods.
Vertical scaling is also preferable when you have other constraints on scaling such as limited IP address space or a limit on the number of nodes imposed by your licence.
When it comes to defining your scaling rules, you need to know the use case of each, the features of your application and which types of scaling demands you’re likely to meet.
5. Use rightsizing
Rightsizing simply means ensuring proper resource utilisation (CPU and memory) across each pod and node in your Kubernetes environment.
If you fail to rightsize, a few things can happen which will impact your application’s performance and cost optimisation efforts.
In the case of overprovisioning, paid-for CPU and memory will go unused. These are idle resources which could have been made use of elsewhere.
In the case of underprovisioning, although it does not impact Kubernetes’ costs directly, it will lead to performance issues, which will ultimately lead to costs down the line.
When it comes to rightsizing, there are a few approaches. It can be done manually by engineers or completely automated using a tool (more on this to come).
Ultimately, rightsizing is a continuous process requiring dynamic adjustments, but when done right, it’s an essential part of your cost optimisation strategy.
6. Making the best use of spot instances
Spot instances are a great fit for some. If your application can handle unpredictability, you can obtain huge discounts on instances (up to 90% on AWS) for a limited amount of time.
However, those looking to reduce costs using spot instances on Kubernetes should bear in mind there may be some additional configuration.
For example, you’ll need to adjust pod distribution budgets and set up readiness probes to prepare your Kubernetes clusters for the sudden removal of instances.
The same goes for node management – you’ll need to diversify your instance types and pods to plan around disruption.
Put simply, spot instances are a great way to reduce costs for the right application, but integrating that unpredictability into Kubernetes requires extra know-how.
7. Be strategic about regional resources to reduce traffic
One often overlooked cost optimisation strategy is reducing traffic from between different geographical regions.
When nodes cover multiple regions, data transfer charges can mount quickly as you’ll be using the public internet to send and receive data.
Here, tools like AWS Private Link and Azure Private Link can help you optimise costs by providing an alternative route.
The regional distribution and data transfer strategy of your clusters can be an involving job, and some will make use of a tool to help them, but once finalised, it’s a great way of cutting your monthly bill.
Ongoing improvements
These are Kubernetes cost optimisation techniques for those who may have already addressed the most common problems and want to implement ongoing improvements.
If you’re well aware of practices like auto-scaling and rightsizing, here are a few down-the-road cost management techniques for more experienced Kubernetes users.
8. Tool up to monitor costs and improve efficiency
Kubernetes, EKS, AKS and GKE all offer their own cost monitoring and optimisation functions. But to gain truly granular insights, it’s often better to invest in a third-party tool.
There are plenty of Kubernetes cost optimisation tools to choose from. And a few more general cloud cost management tools which can work well with Kubernetes infrastructure.
For a thorough look, browse our list of cloud cost optimisation tools which contains a few specialist Kubernetes solutions.
As a general tip, when you’re choosing a tool, it pays to think about what you’re missing most.
Some tools work best for generating insights. Some have a heavy focus on AI, meaning less control and user input, which is great for teams that lack staff resources.
In short, consider what’s missing in your Kubernetes cost optimisation process and pick the right tool for the job.
9. Integrate cost controls into your CI/CD pipeline
If your organisation is using DevOps in conjunction with Kubernetes, you can build Kubernetes cost monitoring and controls into your CI/CD pipeline at various points.
For example, when properly integrated, Kubecost can be used to predict the costs of changes before deployment.
It can also be used to automate cost-related controls, even failing a build if the predicted costs are deemed too high.
In more general terms, integrating Kubecost (or scripts with a similar function) can make Kubernetes costs a monitorable data point to feed into future CI/CD decisions.
So, if you’re using Kubernetes, and your organisation has adopted DevOps, there’s scope for building cost optimisation into the heart of your processes.
10. Build and environment where cost optimisation is embraced through tooling and culture
Although this goes for cloud costs in general, it’s worth taking the time to lay out some key points.
First off, adopting the right mindset across an organisation is going to be easier if you’re already doing some of the post-deployment and ongoing work.
This culture needs data. So having the right cost monitoring and optimisation tools is a good start.
We’ve already mentioned Kubefed. But there are other more comprehensive platforms out there like CAST AI or Densify.
Second, this data needs to be accessible and meaningful to multiple stakeholders. If you have adopted DevOps, this should present less difficulty. But if you haven’t, you may face a little resistance.
Tools like Apptio Cloudability can help with this, providing clear insights into cost with a specific focus on connecting non-technical stakeholders to key stats.
Last, whether you’re looking to cut costs on Kubernetes or cloud in general, you need to foster an environment that rewards continuous improvement. Teams succeed when they have clear reporting across the business, and when each member feels invested in the continuous process of making things better.
On that note…
What if you could flip a switch and save the planet?
As we said at the beginning, cutting usage means cutting carbon, which means saving a piece of the planet.
At Turn It Off, we use our AI-powered platform to make cutting costs and carbon as simple as flipping a light switch.
So, if you’re looking to save on Kubernetes and carbon emissions, why not take complexity out of the equation? By learning your usage patterns, Turn It Off is able to automatically stand down non-production environments when you’re not using them – with minimal configuration.
We do one thing. And we do it well.
All you have to do is sign up.
