Rules
Kubernetes Rules are a set of recommendations based on the applications running in Clusters and aiming to provide visibility into the underutilization of Nodes running within the Clusters. These rules are divided into two categories: Savings and Best Practices.
How to get to Rules:
In Kubernetes, select the Rules option.
Rules
Each rule will have a view with some information as follows:
Nodes Found: Lists the number of Nodes found that apply to the recommendation.
Estimated Savings Cost: Estimated monthly savings cost by implementing the recommendation.
Category: Informs whether the recommendation has any related savings or simply applies to a good practice for using the resource.
By clicking on the rule name in blue, the system will display a graphical view of the recommendation over time and an estimated savings, if it is a savings rule:
Below, you can view a more detailed list with information on all nodes or workloads found that apply to the rule:
For Savings recommendations, information such as:
Node
Node kind
Region
Account ID
Cluster Name
Node Cost (CPU and Memory)
For Good Practices recommendations, information such as:
Application
Cluster Name
Container
Namespace
Application Kind
CPU Limit
By clicking on the name in blue, the system will direct you to more detailed information per application on the Overview page. In the case of Nodes, it will direct you to more detailed information about the Node on the Nodes page.
By clicking on the Filters icon, as shown below:
The system will display all label options collected from the observability platform, allowing you to apply the desired filter field to K8s:
When selecting the desired field, you will be able to provide more information about the filter field, such as:
Enable the negative expressions option if you want to work with a result different from the one reported.
It is equal to: In this case, the desired value must be selected in the return.
Is empty: When an empty result is desired for my return.
Contains: When you want the result to contain a specific value to be reported.
Starts with: When you want the result to start with a specific value to be reported.
Ends with: When you want the result to end with a specific value to be reported.
And by clicking the Save button, the system will display the added filter:
In addition to allowing you to apply a filter field, the system also allows you to apply a competency period:
By clicking on the period option, as highlighted above, the system will open the month informed, allowing you to select a specific day:
When selecting the desired day, clicking on the Reload button, the system will update the page data for the new day informed:
Finally, by clicking on the "
" icon, the system allows you to extract a report in CSV format.
Savings Rules
Nodes with low utilization: Nodes with low CPU and memory utilization indicate idle resources. To optimize costs, these nodes can be removed or resized.
Good Practices Rules
Workloads with CPU Limit: Exceeding the CPU limit leads to vCPU throttling, impacting the performance of all pods on the node due to instruction queuing.
Workloads without CPU Request: Pods without CPU Request can lead to unlimited provisioning, causing throttling of vCPU and impacting performance. CPU reservation tends to significantly improve application performance.
Workloads without Memory Request: The absence of memory request can lead to node memory exhaustion and, consequently, failures. Allocating memory ensures better performance.
Workloads without memory limit: The absence of memory limit on pods can consume all the memory of the node, causing crashes and unnecessary costs, without intervention from the ASG.
Workloads with request and different memory limit: Setting the memory limit higher than the request exposes the node to the risk of crashing due to memory exhaustion, similar to pods without limit.
Last updated