Workload controller resize actions

Resize up actions in response to CPU throttling

For vCPU limit resizes, Turbonomic will recommend a resize up action, even if utilization percentile is low, to address slow response times associated with CPU throttling.

CPU throttling occurs when you configure a CPU limit on a container, which can inadvertently slow your applications' response time. Even if you have more than enough resources on your underlying node, your container workload will still be throttled because it was not configured properly. High response times are directly correlated to periods of high CPU throttling.

Learn more about CPU throttling here.

Especially for sudden throttling spikes, Turbonomic will persist the related resize actions so you can evaluate these actions even after the spikes have gone away, and then execute them to prevent spikes from re-occurring. As throttling drops, Turbonomic will not recommend a resize down action immediately, as this could result in subsequent back-and-forth upsize and downsize recommendations. Instead, it evaluates past throttling to decide when a resize down action is finally safe to execute. To ensure the timeliness of these actions and arrive at the optimal resize values to recommend, Turbonomic calculates fast and slow moving throttling averages, and then displays smoothed and daily averages in charts.

Smoothed average is an exponential moving average and moving variance method used on CPU throttling data. It allows analysis to generate a vCPU limit resize up action more quickly when throttling is detected, and be conservative on resize down to mitigate introducing throttling.

Resizing resource limits and requests

Turbonomic can recommend resizing vCPU/vMem limits and requests. For example, if workloads are allocated more than the requests that they actually use, Turbonomic recommends a resize down action to improve efficiency. If these workloads experience sustained increases in utilization, a resize up action is necessary to avoid performance risks. The net result of all vCPU and vMem resize actions for workload controllers is displayed at the top of the Resize actions view for Workload controllers in the Action center. This value is dynamically updated when actions are selected or deselected in the table.

To generate optimal resize actions, Turbonomic takes into account any analysis properties for resource limits and requests in container spec policies. Analysis properties include capacity ranges and target utilization midpoints.

Turbonomic also checks if requests and limits are specified for workloads.

• If requests and limits are specified, requests can be resized up or down based on actual utilization and target utilization. However, requests cannot exceed limits.

• If limits are specified but requests are not specified, Kubernetes sets requests to be the same value as limits when scheduling a pod. In other words, the capacities of both commodities are equal. Since requests cannot exceed limits, requests can only be resized down based on actual utilization and target utilization.

• If requests are specified but limits are not specified, a limit with a request is not necessary. Turbonomic does not recommend resizing limits.

• If requests and limits are not specified, Turbonomic does not recommend resizing requests or limits.

The following table describes the preceding scenarios in detail.

• For limits

  Table 1. Resizing resource limits

  Item	Resources specified
  	Limits and requests	Limits only	Requests only	No limits or requests
  Limits commodity	Created	Created	Created	Created
  Capacity	From specs	From specs	Node capacity	Node capacity
  Resize up	Yes	Yes	No	No
  Resize down	Yes	Yes	No	No

• For requests

  Table 2. Resizing resource requests

  Item	Resources specified
  	Limits and requests	Limits only	Requests only	No limits or requests
  Requests commodity	Created	Created	Created	Not created
  Capacity	From specs	Requests = limits (set by Kubernetes during scheduling)	From specs	N/A
  Resize up	Yes	No, as long as requests = limits	Yes	No
  Resize down	Yes	Yes	Yes	No

Action propagation

Resize actions propagate to application entities and the underlying container infrastructure to show the impact of these actions on the health of your applications and container environment.

Action merging

Action execution

After you set the scope to workload controllers, go to Action center to see the full list of resize actions that you can execute. This list includes individual and merged actions. You can filter the list to focus on specific actions, such as actions to address resource congestion or vCPU throttling.

By default, resize actions are set in Manual mode at the workload controller level. This means that Turbonomic will not execute any action automatically, and you can manually select the actions that you want to execute. If you prefer to execute actions outside Turbonomic, create workload controller policies and set the resize action acceptance mode to Recommend. To automate actions, create workload controller policies and set the resize action acceptance mode to Automatic.

For each action, click the information icon in the Action column to view the Action details page. This page includes time series charts that explain the reason for the action. These charts highlight utilization percentiles and smoothed throttling averages for a given observation period. Turbonomic uses percentile calculations to make accurate resize decisions.

These charts also:

• Plot daily average percentiles and throttling, for your reference.

• Show projected percentiles after you execute the action. If you have previously executed resize actions on the same workload controller, the charts show the resulting improvements in daily average utilization.

Put together, these charts allow you to easily recognize trends that drive Turbonomic's resize recommendations.

Special cases for workload controller resize actions

Resize actions for certain types of workloads may be blocked or set to recommend-only, which means that they are currently not executable in Turbonomic. These actions usually require a dependent action or an external configuration to be completed first. For example, a workload controller resize up action may be temporarily blocked if there is insufficient resources in the corresponding node or namespace. In this case, a node provision or namespace quota resize action must be completed first.

The following table describes these special cases.

Downloading data for executed resize actions

You can view and download data for executed resize actions to gain insight into workloads with performance risks due to resource limits, as well as opportunities to reclaim unused resource requests.

1. Add the Actions chart to your dashboard.

2. Configure the chart. Be sure to set the scope to workload controllers to narrow the results, select Tabular as the chart type, and then set the filter to either All Actions or Executed Actions.

3. In the chart, click Show All.

4. In the page that opens, click the download button. If you set All Actions as the filter, select Executed Actions.

5. Open the downloaded file and go to the Resize Workload Controller sheet.

   Pay attention to the following columns:

   • Namespace, Container Spec, and Container Platform Cluster columns – Data in these columns is the most up-to-date at the time of download.

   • Change column – This column highlights the impact of resize actions on the resources allocated to containers. Each value represents the difference between the Current Value and New Value columns.

   • Container Spec column – If there is more than one container spec in a workload controller, you can sort this column to easily identify resize actions on individual container specs.

   • Impacted Commodity column – This column shows if VMem or VCPU was resized. A resize action might show both commodities, which indicates that it is a merged action (an action that consolidates resizes related to a single workload controller, to minimize disruptions).