How FederatedHPA Works

How FederatedHPA Works

Figure 1 shows the working principle of FederatedHPA. The details are as follows:

1. The HPA controller periodically requests metrics data of a workload from either the system metrics API or the custom metrics API.
2. After receiving the metric query request, karmada-apiserver routes the request to karmada-metrics-adapter that was registered through its API.
3. After receiving the request, karmada-metrics-adapter collects the metrics data of the workload.
4. karmada-metrics-adapter returns calculated metrics data to the HPA controller.
5. The HPA controller calculates the desired number of pods based on the returned metrics data and maintains the stability of workload scaling.

Figure 1 Working principle of FederatedHPA

How Do I Calculate Metrics Data?

There are system metrics and custom metrics. Their calculation methods are as follows:

• System metrics
  There are two types of system metrics: CPU usage and memory usage. The system metrics can be queried and monitored through metrics API. For example, if you want to control the CPU usage of a workload at a reasonable level, you can create a FederatedHPA for the workload based on the CPU usage metric.

  

  Usage = CPUs or memory used by pods in a workload/Requested CPUs or memory

• Custom metrics

  You can create a FederatedHPA for a workload based on custom metrics such as requests per second and writes per second. The HPA controller then queries for these custom metrics from a series of APIs.

How Do I Calculate the Desired Number of Pods?

The HPA controller operates on the scaling ratio between the desired metric value and current metric value and then uses that ratio to calculate the desired number of pods based on the current number of pods.

• Current number of pods = Number of pods in the Ready state in all clusters

When calculating the desired number of pods, the HPA controller chooses the largest recommendation based on the last five minutes to prevent subsequent autoscaling operations before the workload finishes responding to prior autoscaling operations.

• Desired number of pods = Current number of pods x (Current metric value/Desired metric value)

For example, if the current CPU usage is 100% and the desired CPU usage is 50%, the desired number of pods is twice the current number of pods.

How Do I Ensure the Stability of Workload Scaling?

To ensure the stability of workload scaling, the HPA controller is designed to provide the following functions:

• Stabilization window

  When detecting that the metric data reaches the desired value (the scaling standard is met), the HPA controller continuously checks the metric data within stabilization window. If the result shows that the metric data continuously reaches the desired value, the HPA controller performs scaling. By default, the stabilization window is 0 seconds for a scale-out and 300 seconds for a scale-in. The values can be changed. In actual configuration, to avoid service jitter, a scale-out needs to be fast, and a scale-in needs to be slow.

• Tolerance

  Tolerance = abs (Current metric value/Desired metric value – 1)

  abs indicates an absolute value. If the metric value change is within the specified tolerance range, the scaling operation will not be triggered. The default value is 0.1 and cannot be changed.