Hey, this is AmBlue. How can I help you today?

Categories
Cloud Cost Optimization

Kubernetes Cost Optimization – Best Practices (Part 2)

As businesses continue to embrace Kubernetes for its scalability and agility, cost management becomes increasingly critical. We understand that managing cloud costs can be complex, especially in large and dynamic containerized environments. That’s why we’re here to provide you with practical insights and actionable tips to take control of your Kubernetes spending. In our previous blog on Kubernetes Cost Optimization Best Practices – Part 1, we covered the common cost optimization challenges and a few solutions. Let’s see a few more,

Taints & Tolerances

In Kubernetes, “taints” and “tolerations” are mechanisms that can be used strategically to optimize costs by efficiently managing the allocation of workloads to nodes within your cluster. They act as filters in the Kubernetes world. Some of its uses in optimization are,

Efficient Utilization:

Nodes can be ‘tainted’ based on their utilization or capacity, such as CPU or memory usage. This allows you to mark nodes that are underutilized or overutilized. Whereas pods that are designed to scale horizontally can have ‘tolerations’ for nodes with low utilization. When additional resources are needed, more pods can be scheduled on those nodes to efficiently utilize available resources without provisioning new nodes.

Cost Optimization:

You can create custom ‘taints’ to represent various cost-related attributes, such as GPU availability, network bandwidth, or specific hardware types. Also pods can be configured with ‘tolerations’ that align with your custom cost-based policies. This ensures that workloads are deployed on nodes that match their requirements while considering cost factors.

Example:
Let’s say, your web application includes a background processing component that handles non-critical tasks like generating reports or processing non-urgent user requests. These tasks can tolerate occasional interruptions or delays without impacting the overall user experience.

For this case, Taint the nodes that are running on spot instances to indicate their cost-effectiveness but potential for interruptions.

Result: This taint marks these nodes as suitable for running cost-sensitive workloads.

To schedule less critical pods on spot instance nodes, define tolerations as below,

Result: These tolerations allow the pods to be scheduled on nodes with the “spot-instance” taint.

If a spot instance is reclaimed by the cloud provider, Kubernetes will automatically reschedule these pods on other available nodes, maintaining the desired level of service while optimizing costs.

Sleep Mode

You don’t need all workloads or resources to run 24/7. Especially during non-business hours and weekends. CPU, memory, or storage resources rack up the bills when they are left idle. Putting them into sleep mode with Cronjobs during non-business hours or HPA efficiently scales down the environment when not in use and scales up automatically when needed.

Example: If you want to put your Dev environment to ‘sleep mode’, here’s the code to scale them down at 5.00 P.M. everyday.

Node Pools

Node pools involves grouping nodes with similar characteristics like CPU, memory, etc. This helps in efficient resource management which in turn drives Kubernetes cost optimization. Different cloud providers offer a wide range of VM instance types optimized for various use cases. When you explore the offerings of your chosen cloud provider GCP, AWS, Azure, etc. you can identify instance types that align with your workload requirements. Pay attention to factors like CPU, memory, storage, network performance, and cost.

Kubernetes Cost Monitoring Tools

At Amadis as we always insist, spending is not a bottleneck as long as you SPEND RIGHT on your cloud resources. Spending right starts from analyzing your Kubernetes environment which is possible with Kubernetes cost monitoring tools.

CloudCADI simplifies your complex Kubernetes cost optimization process in a few clicks. Some of its key features are,

Pod-level showback: From your native cloud providers’ bills, you can get the charges of the clusters overall. Whereas in CloudCADI, you have the flexibility to drill down the charges at a lowest possible unit level – pod.

Node resizing:  CloudCADI never stops with the Kubernetes cost and utilization overview. Furthermore, it gives intelligent recommendations on how to alter your resources with choices and savings opportunities. Cloud administrators can simply leverage these options rather than manually evaluating the options.

By implementing these cost optimization tricks and regularly reviewing your Kubernetes environment for inefficiencies, you can effectively manage your infrastructure costs while ensuring optimal performance and resource utilization.

SPEND RIGHT on cloud with CloudCADI today.

Categories
Cloud Cost Optimization Cloud FinOps

Kubernetes Cost Optimization Best Practices – Part 1

Cloud containers come with the flexibility to lift and shift applications to any environment, cloud or virtual, or bare metal without worrying about the virtual OS, hypervisors, etc.  Simplified management, paced-up delivery, and agility compel cloud developers to hail containerization. Kubernetes aka k8s (if you are wondering what k8 means, it’s just a replacement of 8 letters “ubernete”) is a popular open-source containerization platform cloud developers adopt widely. According to a recent report by CNCF, there is a 67% increase in Kubernetes developers worldwide which manifests the popularity.

The sad news is the surge in adoption and usage comes with a compromise in the IT infrastructure budget. Enterprises could be wasting nearly 80% of Kubernetes expenses on unintentional resources that are not helping organizations to hit their goals as planned. Let’s see in this blog what are the challenges and ways to optimize.

Challenges in Kubernetes Cost Optimization

Charged as a whole:

A cluster contains multiple nodes within. Each node will, in turn, contain a varying number of containers. Every node that is present inside one cluster is not necessarily part of the same application as others. Each node may be handled by 20 different teams for different applications. But the cluster is charged as a whole or clusters together by the cloud service providers. Billing starts right when a container is deployed into a node. The additional cost of $2.4/day is charged for Kubernetes cluster maintenance, software license, disaster recovery, etc.

Showback and chargeback – Near Impossible:

These two processes are vital for enterprises to bring financial accountability. (Showback is the process that gives visibility to a business unit’s expenses on cloud resources usage for a particular period but not charged. Whereas chargeback is where the unit is informed as well as charged based on its utilization.) Tagging, which can aid the engineers in cost tracking is not possible in Kubernetes clusters.

Every penny we invest becomes worthy when it checks the list of features/output we planned. When they just stay at the expense side mapped to no production, then the ultimate source for the anomalies should be identified. But it is not as simple as it sounds for Kubernetes clusters. Spotting the team responsible for most of the expenses is daunting as each container may be utilized by different teams in the enterprise working on different deliverables. Each team’s Infrastructure budget and resource cost allocation varies on the other hand.

Multi-cloud adoption:

In Gartner’s recent survey, 81% of the respondents stated that they use 2 or more cloud service providers to avail of various benefits like overcoming vendor- lock-in, resource discounts, disaster recovery, etc. Kubernetes clusters will contain workloads from different cloud service providers like AWS, Azure, GCP, etc. which further twists the cost anomalies detection and Kubernetes cost optimization process.

Dynamic Autoscaling

One of the key reasons for cloud engineers to choose the Kubernetes cluster is its autoscaling feature. Depending on the usage demand, Kubernetes scales up or down so the resources suffice the compute requirement during peaks and valleys. Further in horizontal autoscaling, containers scale out which may reach from 2 to 20 within a day. Kubernetes cost optimization turns complicated because of this unpredicted autoscaling.

Kubernetes Cost Optimization Best Practices

Let’s look at the optimal ways to trim the inadvertent expenses.

 

  1. Quality of Services for Pods (QoS)

Kubernetes cluster offers cloud practitioners the flexibility to set different QoS classes to Pods. Based on this the Pods’ scheduling and removal become easier for cloud practitioners. It is of 3 types – Guaranteed, Burstable, and Best-Effort.

Guaranteed: 

When cloud engineers need to have a Pod, whose instances are sufficient to handle a highly critical app, they can configure it to be a guaranteed QoS class. So, both the CPU & memory limits and requests are the same and set. As the name suggests it guarantees minimal resources (Requests are the minimum number of resources and limits are the maximum resources it can use)

Burstable:

 A Burstable QoS class is assigned for a Pod when the vCPU or memory limit is more than the requests or not essentially the same. So, when the need arises for a spiked compute requirement, they can be utilized.

Best-Effort:

When both the limits and requests are not set, it is classified as a best-effort QoS class. Cloud engineers can avail for non-critical applications.

As we can clearly witness, Best-effort pods are the first choice for removal followed by Burstable and then Guaranteed.

Related reading: How to configure pods and containers?

2. ResourceQuotas & LimitRange

As we saw earlier, the Kubernetes cluster is shared by various teams. There is a possibility that one team may consume most of the Pods leaving other teams scarce. Namespace-level Pod restriction can mitigate this issue (Namespace is a virtual cluster). ResourceQuota is the means through which we can limit Pods’ usage within a Namespace.

Kubernetes administrators create a ResourceQuota for each Namespace. Whenever a user creates or updates a Pod within a Namespace, the ResourceQuota system checks if the limits are exceeded,  If it is crossing the limits, it returns a “403 FORBIDDEN” error denying the action.

LimitRange is another policy that helps with resource constraints individually. As the name goes limits the range of “limits & requests” within a Namespace.

3. Affinity

Pod/Node Affinity helps in influencing the pod scheduling that helps in resource optimization and, in turn the cost. Even though the scheduler does its job of equally spreading pods across the nodes, for some special cases like, when an application requires a specific hardware or licensing constraints, we can use Node Affinity to schedule pods onto specific nodes. This in turn avoids over provisioning of expensive resources and kubernetes cost management.

It is not done. Looking for more optimal ways to cut down Kubernetes costs? Read our next blog here : Kubernetes Cost Optimization Best Practices – Part 2

Kubernetes Cost management can turn simple when you use CloudCADI. Try a demo today.

SPEND RIGHT on Cloud with CloudCADI.

Individual privacy preferences

We use cookies and similar technologies on our website and process your personal data (e.g. IP address), for example, to personalize content and ads, to integrate media from third-party providers or to analyze traffic on our website. Data processing may also happen as a result of cookies being set. We share this data with third parties that we name in the privacy settings.

The data processing may take place with your consent or on the basis of a legitimate interest, which you can object to in the privacy settings. You have the right not to consent and to change or revoke your consent at a later time. For more information on the use of your data, please visit our privacy policy.

Below you will find an overview of all services used by this website. You can view detailed information about each service and agree to them individually or exercise your right to object.

Essential services are required for the basic functionality of the website. They only contain technically necessary services. These services cannot be objected to.  •  Show service information