Creating an HPA Policy

Prerequisites

Constraints

• HPA policies can be created only for clusters v1.13 or later.
• For clusters earlier than v1.19.10, if an HPA policy is used to scale out a workload with EVS volumes mounted, the existing pods cannot be read from or written to when a new pod is scheduled to another node.

  For clusters v1.19.10 and later, if an HPA policy is used to scale out a workload with EVS volumes mounted, a new pod cannot be started because EVS disks cannot be attached.

• If pods in a cluster are scheduled to CCI 2.0 using the CCE Cloud Bursting Engine for CCI, the Kubernetes Metrics Server add-on cannot collect metrics for those pods. As a result, HPA may not function correctly. To ensure HPA works properly, replace Kubernetes Metrics Server with Cloud Native Cluster Monitoring. For details, see Auto Scaling.

Procedure

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. Choose Workloads in the navigation pane. Locate the target workload and choose More > Auto Scaling in the Operation column.
   Figure 1 Scaling a workload
   

3. Set Policy Type to HPA+CronHPA, enable the created HPA policy, and configure parameters.

   This section describes only HPA policies. To enable CronHPA, see Creating a Scheduled CronHPA Policy.

   Figure 2 Enabling the HPA policy
   

   Table 1 HPA policy

   Parameter	Description
   Pod Range	Minimum and maximum numbers of pods. When a policy is triggered, the workload pods are scaled within this range. NOTICE: In CCE Turbo clusters, if you use a dedicated load balancer for your workload, the number of pods cannot exceed the backend server group quota of the load balancer, which is 500 by default. If you exceed this limit, you will not be able to add any more pods to the load balancer backend.
   Cooldown Period	Interval between a scale-in and a scale-out. The unit is minute. The interval cannot be shorter than 1 minute. This parameter is supported only in clusters v1.15 to v1.23. This parameter indicates the interval between consecutive scaling operations. The cooldown period ensures that a scaling operation is initiated only when the previous one is completed and the system is running stably.
   Scaling Behavior	This parameter is supported only in clusters v1.25 or later. Default: scales workloads using the Kubernetes default behavior. For details, see Default Behavior. Custom: scales workloads using custom policies such as stabilization window, steps, and priorities. Unspecified parameters use the values recommended by Kubernetes. Disable scale-out/scale-in: Select whether to disable scale-out or scale-in. Stabilization Window: a period during which CCE continuously checks whether the metrics used for scaling keep fluctuating. CCE triggers scaling if the desired state is not maintained for the entire window. This window restricts the unwanted flapping of pod count due to metric changes. Step: specifies the scaling step. You can set the number or percentage of pods to be scaled in or out within a specified period. If there are multiple policies, you can select the policy that maximizes or minimizes the number of pods.
   System Policy	When calculating the number of pods to add or remove, HPA determines the target number of pods based on the current metric value, desired value, and the current number of pods. The current number of pods is the maximum number of pods in the last 5 minutes. The formula is as follows: Desired number of pods = Rounded up value of [Current number of pods × (Current metric value/Desired value)] Metric: You can select CPU usage or Memory usage. Usage = Average resource usage of all pods in a workload/Requested resources Desired Value: Enter the desired average resource usage. Tolerance Range: Scaling is not triggered when the metric value is within the tolerance range. The desired value must be within the tolerance range.
   Custom Policy (supported only in clusters v1.15 or later)	NOTE: Before creating a custom policy, install an add-on that supports custom metric collection (for example, Prometheus) in the cluster. Ensure that the add-on can collect and report the custom metrics of the workloads. For details, see Monitoring Custom Metrics Using Cloud Native Cluster Monitoring. Metric Name: name of the custom metric. You can select a name based on suggested values. Metric Source: Select an object type from the drop-down list. You can select Pod. Desired Value: the average metric value of all pods. Number of pods to be scaled (rounded up) = (Current metric value/Desired value) × Current number of pods NOTE: When calculating the number of pods to be added or reduced, the HPA policy uses the maximum number of pods in the last 5 minutes. Tolerance Range: Scaling is not triggered when the metric value is within the tolerance range. The desired value must be within the tolerance range.

4. Click Create.

Common Issues

• Container memory metrics displayed in monitoring differ from those used by HPA. This discrepancy may cause unexpected scaling behavior. For details, see Why Is the Reported Container Memory Usage Inconsistent with the Auto Scaling Action?

Helpful Links

• To use custom metrics for auto scaling, see Creating an HPA Policy with Custom Metrics.
• To configure auto scaling based on metrics (CPU and memory usage) or at specific times (daily, weekly, monthly, or yearly), see Creating a CustomedHPA Policy.
• To scale pods periodically using a Crontab-like schedule, see Creating a Scheduled CronHPA Policy.
• To automatically adjust pod resource limits based on actual usage, see Creating a VPA Policy.
• For periodic resource usage that cannot be defined by fixed rules, use AHPA policies. AHPA automatically identifies the scaling period based on historical metrics and performs scaling. For details, see Creating an AHPA Policy.
• Use HPA with node auto scaling to automatically add nodes when cluster resources are insufficient. For details, see Using an HPA and a CA for Auto Scaling of Workloads and Nodes.
• To autoscale GPU-based workloads using GPU monitoring metrics, configure HPA. For details, see Configuring Workload Scaling Based on GPU Monitoring Metrics.
• To autoscale based on ELB metrics (such as QPS), see Scaling Based on Load Balancer Monitoring Metrics.
• To autoscale based on Nginx ingress metrics, see Scaling Multiple Applications Using Nginx Ingresses.