tencent cloud

Feedback

Cluster Autoscaler

Last updated: 2024-06-14 16:28:43

    Overview

    Component Overview

    The Cluster Autoscaler (CA) component offers auto-scaling (AS) capabilities for clusters based on simulated scheduling algorithms. It supports adding new nodes when resources are scarce and removing old nodes when resources are idle.
    Note
    This component must be used in conjunction with a node pool, and now it supports native nodes and regular nodes.
    To use this capability, ensure that the node pool has AS enabled.

    Kubernetes objects deployed in a cluster

    Kubernetes Object Name
    Type
    Resource Amount
    Namespace
    cluster-autoscaler
    PodDisruptionBudget
    -
    kube-system
    cluster-autoscaler
    ServiceAccount
    -
    kube-system
    cluster-autoscaler
    Secret
    -
    kube-system
    cluster-autoscaler
    ClusterRole
    -
    -
    cluster-autoscaler
    ClusterRoleBinding
    -
    -
    cluster-autoscaler
    Role
    -
    kube-system
    cluster-autoscaler
    RoleBinding
    -
    kube-system
    cluster-autoscaler
    Service
    -
    kube-system
    cluster-autoscaler
    Deployment
    0.5C1G (for new creations)
    kube-system

    Application Scenario

    When instances (pods) in the cluster cannot be scheduled due to insufficient resources, an auto scale-out action is triggered to add nodes of an appropriate type through simulated scheduling, reducing your labor costs.
    When scale-in conditions are met, an auto scale-in action is triggered to remove nodes, saving you resource costs.

    Limits

    Kubernetes cluster version: 1.16 or later

    Component Principles

    Scale-out Principle

    1. When the cluster lacks sufficient resources (the cluster's compute/storage/network resources cannot meet the Request/Affinity rules of pods), CA detects pods that are pending due to unschedulability.
    2. CA makes scheduling decisions based on the node template of each node pool, selecting the appropriate node template.
    3. If multiple templates are suitable, meaning there are multiple scalable node pools available, CA will call expanders to select the optimal template and scale out the corresponding node pool.

    Scale-in Principle

    1. CA detects that the allocation rate (namely, the Request value, which takes the maximum value of the CPU allocation rate and MEM allocation rate) is lower than the threshold specified for a node. When calculating the allocation rate, you can set the Daemonset type not to count in a pod's occupied resources.
    2. CA checks whether the cluster's status meets the following requirements for triggering a scale-in action:
    Node idle duration requirement (default: 10 minutes)
    Cluster expansion buffer time requirement (default: 10 minutes)
    3. CA checks whether a node meets the conditions for scale-in. You can configure the following do-not-remove conditions as needed (nodes that meet these conditions will not be removed by CA):
    Nodes containing local storage.
    Nodes containing pods that are not managed by DaemonSet in the kube-system namespace.
    4. After evicting the pods on the node, CA releases/shuts down the node.
    Completely idle nodes can be removed in batches. (The maximum number of nodes that can be removed in a batch can be set.)
    Non-completely idle nodes are removed one by one.
    

    Parameter description

    Module
    Functional Item
    Parameter Value Description
    Scale-out
    Scale-out Algorithm
    **Random (default)**: If there are multiple scalable node pools, any one of them will be selected for scaling out.
    Most-pods: If there are multiple scalable node pools, the node pool running the highest number of pods will be selected for scaling out.
    Least-waste: If there are multiple scalable node pools, the node pool with the least resource waste will be selected for scaling out.
    Priority: If there are multiple scalable node pools, the node pool with higher priority will be selected for scaling out according to your custom ConfigMap (see below for details). This feature is only supported by native node pools and is ineffective for regular node pools.
    Scale-in
    Maximum Concurrent Scale-downs
    The number of nodes that can be removed in a batch during a scale-in action.
    Note: Only completely idle nodes are removed in a batch. Nodes that contain any pods are removed one by one.
    Scale-in Conditions
    Threshold: Scale-in conditions are evaluated when the percentage of resources occupied by pods to allocable resources is less than x%.
    Trigger latency: A node is removed after being continuously idle for x minutes.
    Silent period: Scale-in conditions are evaluated x minutes after the cluster is scaled out.
    Do Not Scale Down Nodes
    Nodes containing pods with local storage (including hostPath and emptyDir).
    Nodes containing pods that are not managed by DaemonSet in the kube-system namespace.

    ###Using a Scale-out Algorithm Based on the Priority in Custom ConfigMap

    Note
    This feature is only supported by native node pools and is ineffective for regular node pools.
    Priority values range from 1 to 100 and must be positive integers.
    A node pool ID maps one and only one priority.
    If the node pool ID is not configured in ConfigMap, even if scale-out requirements are met, the scale-out action will not be performed because the priority is not configured.
    Below is a sample:
    apiVersion: v1
    data:
    priorities: |-
    100:
    - np-l5wmakan #np-l5wmakan (node pool ID) has a priority of 100.
    50:
    - np-9r9rh7kp #np-9r9rh7kp (node pool ID) has a priority of 50.
    kind: ConfigMap
    metadata:
    name: cluster-autoscaler-priority-expander #The name must be set to cluster-autoscaler-priority-expander.
    namespace: kube-system

    Related Links

    
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support