Kubernetes Cost Optimization.

Kubernetes Cost Optimization.

Many Kubernetes deployments focus on technical operations capabilities and fail to consider the costs associated with their benefits. When cutting cloud costs, organizations must consider cost-management best practices, but Kubernetes deployments might require special attention.

How to reduce the cost of Kubernetes

Pod rightsizing

Kubernetes Pods are a construct that contains one or more containers that act as a single block of resources that can be scheduled and scaled on the cluster, and are the smallest deployable unit in a Kubernetes container environment.

When configuring your Kubernetes cluster, you can use resource requests and limits, where developers control the amount of CPU and memory resources per pod or container by setting the resource request and limit fields in the configuration file. Kubernetes will take the declared resource request and limit at face value, guaranteeing at least the request value, but allowing up to the limit value to be consumed.

To help reduce the cost of your Kubernetes cluster, ensure that you’re setting resource requests and limits that provide enough resources for optimal performance, but not so much that there’s waste. Examine your pod usage and application performance over time to determine if you can rightsize your pods by adjusting your requests and limits. 

Kubernetes also offers a tool called the Vertical Pod Autoscaler (VPA). The VPA automatically allocates more or less CPU and memory to existing pods.

Node rightsizing

Similar to rightsizing your pods, it’s important to make sure you’re using the right size and type of node in your Kubernetes cluster for the workloads you’re running. As a simple example, let’s say you have a node with 10 CPUs and 10 GB of RAM that costs $100/month. You also have a workload that requires 4 CPUs and 4 GB of RAM to run. You can fit up to two pods of this workload in your node, but there isn’t enough room for a third. You would need to add an additional node, which increases wasted resource space in your nodes and drives up costs. To reduce wasted spend and resources for that particular workload, it would be better to use a node with 8 CPUs and 8 GB of RAM. 

The simple takeaway here is similar to pod rightsizing—be sure to measure what your applications require and reduce the number and size of your nodes where possible.

However, in terms of performance, it’s important to keep in mind that if the number of pods per node becomes too large, operations might slow down and can even become unreliable. Because of this, managed Kubernetes services usually impose limits on the number of pods per node. Here’s a quick breakdown of the leading cloud providers’ pod-per-node limits:

  • On Amazon Elastic Kubernetes Service (EKS), the maximum number of pods per node depends on the node type and ranges from four to 737.
  • On Google Kubernetes Engine (GKE), the limit is 110 pods per node, regardless of the type of node.
  • On Azure Kubernetes Service (AKS), the default limit is 30 pods per node but it can be increased up to 250.

Autoscaling

By rightsizing your pods and nodes, you can improve the performance and reduce the cost of your Kubernetes clusters. However, it’s challenging to know the exact number of pods or nodes that best fit the services you’re running and to adapt quickly when changes occur. To help with this challenge, Kubernetes offers autoscaling capabilities to ensure you’re using the right size and number of pods, nodes, and clusters for your needs. Luckily, there are tools in Kubernetes for managing the number of active pods and nodes: 

  • The Horizontal Pod Autoscaler (HPA) increases or decreases the number of pods you run based on observed pod CPU or memory utilization. To learn more about how this is done in practice, see the Kubernetes documentation on the Horizontal Pod Autoscaler here
  • The Cluster Autoscaler automatically increases or decreases the size of your Kubernetes cluster by adding or removing nodes, based on pod and node utilization metrics. You can learn more about the Cluster Autoscaler here

Applications have different needs with different patterns. Ensuring your application not only scales up when necessary, but also scales down at the appropriate times, can save you significant costs.

Cost Management Tools

To start cost-management initiatives, decide on a Kubernetes cost-management tool. Most enterprises trying to analyze and reduce Kubernetes costs use Kubecost, an open source tool that analyzes the IT environment to recommend cost-reduction strategies. While Kubecost is a great enterprise strategy, it's overkill for smaller organizations or companies with limited Kubernetes use. Some users prefer other tools, such as CloudForecast. Kubernetes monitoring tools can also drive cost analysis and optimization, but require more work.

It's important that Kubernetes cost-management tools and practices accommodate chargeback and cost-review policies. Most organizations don't monitor cloud costs centrally if they're allocated to business units, and this can leave major holes in cost visibility. If Kubernetes deployments share components, it can be difficult to discern whether they're inefficient or used more widely than expected.

 Rebalancing fragmented Kubernetes nodes

With time, any active Kubernetes cluster goes through a recurring series of deployments and periodic scale-out, which translates to repeated pod/node additions and removals. This cycle generally introduces several inefficiencies in the clusters. A few of them can often be addressed by the three steps we’ve already covered—rightsizing pods, rightsizing nodes, and autoscaling. However, one of the most significant (but rarely addressed) problems is that of resource fragmentation in Kubernetes clusters, which requires special attention.

Since Kubernetes schedulers cannot predict the future pod sizes and node additions, over time, a lot of inconsistencies get introduced in the way pods are scheduled. Inadvertently, pods are eventually scheduled across nodes in such a way that for any new pod, all the resources requested by it are collectively unavailable at any single node, making the pod un-schedulable. Even though your overall cluster might have much more capacity available across the nodes, a scale-up is still needed. It creates a "pseudo" resource crunch that could be avoided by consolidating these fragments of available resources together. 

This can be achieved by identifying and migrating a certain set of pods across the nodes to consolidate available resources together. In large-scale clusters, it’s especially important to rebalance unoptimized Kubernetes clusters like this to avoid wasted resources and unnecessary cloud costs. 

In sum, rebalancing Kubernetes clusters is about performing best practices one, two, and three (pod rightsizing, node rightsizing, and autoscaling) in an integrated way and on an ongoing basis. 

However, if you have hundreds or thousands of pods, identifying the migration plan of pods around the nodes can be nearly impossible, more so because of multiple resources to balance out (like CPU and Memory).

Leveraging efficient purchasing options

Major cloud providers offer different resource purchasing options, with several discounted price options in exchange for modified service contract terms. These resource purchasing options apply to Kubernetes just as they would to non-containerized infrastructure. For example:

  • On-demand Instances: Pay by the hour or second for the instances that you launch
  • Savings Plans: Reduce your Amazon node costs (EC2 or Fargate) by making a commitment to a consistent amount of usage, in USD per hour, for a term of one or three years (only applicable for AWS)
  • Reserved Instances: Receive a discounted price in return for committing to pay for resources for one or three years (Azure calls these “Reservations” and Google Cloud calls these “Committed Use Discounts”)
  • Spot Instances: Request unused instances in exchange for a discounted rate compared to on-demand prices (Azure calls these “Azure Spot VMs” and Google calls these “Preemptible VMs”)


To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics