{"id":6235,"date":"2022-10-27T10:06:58","date_gmt":"2022-10-27T09:06:58","guid":{"rendered":"https:\/\/cloudification.io\/2022\/10\/27\/minikube-copy\/"},"modified":"2025-01-08T17:27:14","modified_gmt":"2025-01-08T16:27:14","slug":"kubernetes-autoscaling-autoscaler-types","status":"publish","type":"post","link":"https:\/\/cloudification.io\/de\/cloud-blog\/kubernetes-autoscaling-autoscaler-types\/","title":{"rendered":"Kubernetes Autoscaling"},"content":{"rendered":"
<\/div>\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Kubernetes Autoscaling<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Kubernetes is a versatile system that lets you automate many management tasks, this includes provisioning and scaling of both workloads and underlying infrastructure. Scalability is one of the main features of Kubernetes.<\/span><\/p>

Managing a Kubernetes cluster is no easy task. The larger the cluster, the larger the number of deployed pods needed to spread the load on the system. This constitutes two types of problems, you can either run out of nodes to host those pods, or have too many that are unused whenever the load decreases.<\/span><\/p>

Automating scaling can help you with these problems, since it is a lot quicker than having to manually allocate resources, add or remove nodes. Automation allows you to respond quicker to peaks in demand, and reduce costs by scaling down when resources are not needed.<\/span><\/p>

Understanding the different types of Autoscalers is crucial for getting the most out of your Kubernetes platform.<\/span>

<\/span><\/p>

Let\u2019s dive into it!<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Types of AutoScalers\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

There are three types of autoscaling available in Kubernetes, two of them are pod-based and one is node-based:<\/span><\/p>

  • Pod scaling:<\/b>
    • Horizontal Pod Autoscaler (HPA):<\/strong> adjusts the number of replicas of an application controlled by a Deployment, ReplicaSet, etc.
      <\/span><\/li>
    • Vertical Pod Autoscaler (VPA):<\/strong> adjusts the resource requests and limits of a container.

      <\/span><\/li><\/ul><\/li>
    • Node-based scaling:<\/b>
      • Cluster Autoscaler (C<\/strong>A):<\/strong> adjusts the number of nodes in the cluster when pods fail to schedule or when nodes are underutilized.<\/span><\/li><\/ul><\/li><\/ul>

        \u00a0<\/p>

        Basically there are three ways in which Kubernetes can autoscale and these are either by adjusting the capacity of pods (<\/span>vertical autoscaling<\/span><\/i>), by adjusting the number of pod replicas (<\/span>horizontal autoscaling<\/span><\/i>), and\/or by adding or removing nodes in a cluster (<\/span>cluster autoscaling<\/span><\/i>).\u00a0<\/span><\/p>

        When combined, these three dimensions offer great benefits, such as that services run with high stability while at maximum load, and at the same time minimizing costs when the demand is low.<\/span><\/p>

        There is a delicate balance to be kept between maintaining an efficient performance and avoiding overprovisioning.<\/span><\/p>

        Let\u2019s take a look at each of these approaches in detail:<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t

        1. Vertical Pod Autoscaler (VPA)\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        The VPA is a component you install in your cluster. It can increase or decrease the request and limit of a pod\u2019s CPU and memory in relation to the actual workload. When the workload demand increases, the VPA will increase the resource limits for a pod and conversely, the VPA will decrease the resource limits as the workload demand decreases. These adjustments are based on historical resource usage measurements.<\/span><\/p>

        A correct implementation of this tool will ensure that the resources of a Kubernetes cluster are allocated efficiently and automatically.\u00a0<\/span><\/p>

        With VPA you can configure two types of resources, namely <\/span>requests <\/b>und <\/span>limits<\/b>. The former sets the minimum amount of resourcer that a container needs, while the latter defines the maximum amount of resources that a container can use, preventing it from consuming more than the amount you have previously set. <\/span>Kubernetes scheduler will take care of arranging the pods in cluster based on their requests.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t
        \n\t\t\t\t\t\t\t
        \n\t\t\t
        <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t

        VPA Components \n\n<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        VPA Recommender:<\/b><\/p>

        • Monitors resource utilization and computes target values.<\/span><\/li>
        • Looks at the metric history, OOM events, and the VPA deployment spec of a deployment and makes recommendations for a workload’s resource requests<\/span><\/li>
        • The limits are raised\/lowered based on the limits-requests proportion defined.<\/span><\/li>
        • Can be used by itself when you are not sure what the application actually needs<\/span><\/li>
        • The recommendations are stored in the status field of the workload’s corresponding VPA API object<\/span><\/li><\/ul>

          VPA Updater:<\/b><\/p>

          • Responds to the recommendations based on the update policy defined in the VPA API object.<\/span><\/li>
          • Evicts those pods that need the new resource limits.<\/span><\/li>
          • Implements whatever the VPA Recommender recommends if \u201cupdateMode: Auto\u201c is set.<\/span><\/li><\/ul>

            VPA Admission Controller:<\/b><\/p>

            • Changes the CPU and memory settings (using a webhook) before a new pod starts whenever the VPA Updater evicts and restarts a pod.<\/span><\/li>
            • Evicts a pod if it needs to change the pod’s resource requests when the Vertical Pod Autoscaler is set with an updateMode of “Auto.\u201d Due to the design of Kubernetes, the only way to modify the resource requests of a running pod is to recreate the pod.<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t\t
              \n\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t
              \n\t\t\t
              <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t

              How does it work?\n<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t\t
              \n\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t

              You can choose to either configure the VPA or to run it in recommendation mode.<\/span><\/p>

              With the <\/span>recommendation mode<\/b>, the VPA Recommender updates the status field of the workload\u2019s Vertical Pod Autoscaler resource with its suggested values. It however, does not terminate pods or alter pod API requests.\u00a0<\/span><\/p>

              If you choose to <\/span>configure the VPA<\/b>, this is what happens:<\/span><\/p>

              1. VPA Recommender reads the VPA configuration and monitors the metrics across all pods of a deployment<\/span><\/li>
              2. VPA provides a recommendation for pod resource allocation<\/span><\/li>
              3. VPA Updater reads the pod resource recommendations<\/span><\/li>
              4. VPA <\/span>updates <\/b>the runtime resource configuration as per the recommendation<\/span><\/li>
              5. Pods are <\/span>resized or terminated<\/b><\/li>
              6. Once the pod is terminated, the deployment recreates the pod to <\/span>match its replica<\/b> configuration<\/span><\/li>
              7. During the pod recreation process, the VPA Admission Controller gets the pod resource recommendation. VPA cannot update existing pods with new limits because Kubernetes does not support dynamically changing the resource limits of a running pod. Therefore it <\/span>terminates <\/b>pods that are using outdated limits. When the pod\u2019s controller requests the replacement from the Kubernetes API service, the VPA Admission Controller injects the updated resource request and limit values into the new pod\u2019s specification.<\/span><\/li>
              8. VPA Admission Controller overwrites the recommendations to the pod.\u00a0<\/span><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t
                \n\t\t\t
                <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t\t
                \n\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t
                \n\t\t\t
                <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t

                Limitations<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t\t
                \n\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t
                • Updating running pods is still experimental<\/span><\/li>
                • Performance in large clusters remains untested<\/span><\/li>
                • All running containers may restart if the VPA recreates pods on a different node when updating pod resources<\/span><\/li>
                • Not the best for applications that are very small, since the minimum memory allocation the VPA can recommend is 250 MiB. Meaning, if your requests are smaller than 250 MiB, it will be automatically increased to fit this minimum.<\/span><\/li>
                • It cannot be used on individual pods which don\u2019t have an owner (controller).<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t\t
                  \n\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t
                  \n\t\t\t
                  <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t

                  Best Practices\n<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t\t
                  \n\t\t\t
                  \n\t\t\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t
                  • DO NOT use <\/span>HPA <\/b>together with <\/span>VPA <\/b>for the same set of pods, <\/span>unless you configure the HPA to use either custom or external metrics<\/span>. HPA scales based on the same resource <\/span>metrics <\/b>(CPU and MEMORY) usage. When a metric reaches its defined threshold, the scaling event will happen for both VPA and HPA simultaneously, which very likely will lead to issues.

                    <\/span><\/li>
                  • Use <\/span>VPA <\/b>together with<\/span> Cluster Autoscaler<\/b>. VPA might recommend more resources than available in the cluster. This can make pods go into a pending status preventing these to be assigned to a node due to insufficient resources causing pods to never run. The <\/span>cluster autoscaler<\/b> can help overcome this limitation by spinning up new nodes in response to pending pods. Another possible solution would be setting the LimitRange to the maximum available resources, ensuring that pods do not request more resources than the LimitRange defines.<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t\t
                    \n\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t
                    \n\t\t\t
                    <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t

                    2. Horizontal Pod Autoscaler (HPA)<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t\t
                    \n\t\t\t
                    \n\t\t\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t

                    HPA adjusts the number of pod replicas of an application based on CPU utilization. More pods are added as the workload demand increases, which means that pods are removed as the demand slows down. By replicating or terminating pods in a replication controller – <\/span>Deployment<\/span><\/i>, <\/span>ReplicaSet<\/span><\/i>, or <\/span>StatefulSet<\/span><\/i>, the HPA affects the total pod count. It is called <\/span>horizontal <\/span><\/i>scaling because it affects the number of instances rather than the resources allocated to a single container.<\/span><\/p>

                    After the initial configuration, the scaling works automatically. The user sets the MIN and MAX number of replicas and the HPA controller checks the metrics with the help of the Metrics Server to then decide to scale your replicas up or down accordingly. Metrics are checked every 15 seconds by default.<\/span><\/p>

                    The Metrics Server captures data (CPU and memory usage for nodes and pods) from <\/span>kubernetes.summary_api<\/span><\/i> and then provides standard resource usage measurement data. It also can collect data from external sources, providing access to custom metrics such as the number of active sessions on a load balancer indicating traffic volumes.<\/span><\/p>

                    You can pair the HPA automatic scaling with some manual adjustments such as:\u00a0<\/span><\/p>

                    • adjusting replica count based on the time of the day;<\/span><\/li>
                    • set different capacity requirements for weekends or off-peak hours;<\/span><\/li>
                    • or apply an event-based replica capacity schedule to help account for predictable load fluctuations.<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t
                      <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t

                      How HPA works<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t

                      HPA works in a loop that constantly checks, compares and updates metrics and then decides to increase or decrease the number of replica pods to achieve the target value. Here\u2019s how each of the steps in that loop works:<\/span><\/p>

                      1. HPA continuously monitors the metrics server for resource usage across all pods of a deployment<\/span><\/li>
                      2. The number of required replicas is calculated based on the collected resource usage<\/span><\/li>
                      3. The metrics are compared with the target value, if they indicate that the target threshold is breached, HPA sends a \u201cScale\u201d request to the Kubernetes Master component<\/span><\/li>
                      4. HPA decides to scale up (or down) the application to the desired number of replicas<\/span><\/li>
                      5. Kubernetes Master then changes the desired number of replicas<\/span><\/li>
                      6. Steps repeat\u00a0<\/span><\/li><\/ol>

                        The HPA control loop chooses the largest pod count recommendation in the last five minutes in order to avoid thrashing. Thrashing happens when the HPA performs subsequent autoscaling actions before the workload finishes responding to prior autoscaling actions.\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

                        \n\t\t\t\t\t\t
                        \n\t\t\t\t\t
                        \n\t\t\t
                        \n\t\t\t\t\t\t
                        \n\t\t\t\t
                        \n\t\t\t\t\t\t\t
                        \n\t\t\t
                        <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                        \n\t\t\t\t
                        \n\t\t\t\t\t

                        HPA Limitations <\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                        \n\t\t\t\t\t\t
                        \n\t\t\t\t\t
                        \n\t\t\t
                        \n\t\t\t\t\t\t
                        \n\t\t\t\t
                        \n\t\t\t\t\t\t\t\t\t
                        • Using HPA together with VPA on memory or CPU when evaluating CPU or memory metrics can be problematic.

                          <\/span><\/li>
                        • You cannot configure HPA on a ReplicaSet or Replication Controller when using a Deployment. You can only do it on the Deployment itself.

                          <\/span><\/li>
                        • HPA does not work with DaemonSets (obviously there is 1 DS per node.)

                          <\/span><\/li>
                        • You could end up either wasting resources or terminating your pods too frequently if your <\/span>CPU and memory limits on pods<\/span> are not set correctly.

                          <\/span><\/li>
                        • HPA can\u2019t scale up until new nodes are added to the cluster whenever the cluster is out of capacity. In this case you can use Cluster Autoscaler (CA) to automate this process.<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                          \n\t\t\t\t\t\t
                          \n\t\t\t\t\t
                          \n\t\t\t
                          \n\t\t\t\t\t\t
                          \n\t\t\t\t
                          \n\t\t\t\t\t\t\t
                          \n\t\t\t
                          <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                          \n\t\t\t\t
                          \n\t\t\t\t\t

                          Best Practices<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                          \n\t\t\t\t\t\t
                          \n\t\t\t\t\t
                          \n\t\t\t
                          \n\t\t\t\t\t\t
                          \n\t\t\t\t
                          \n\t\t\t\t\t\t\t\t\t
                          • Make sure all pods have resource requests configured. All resource request values of all containers should be used so that the data that is needed for making scaling decisions is accurate.<\/span><\/span>

                            \u00a0<\/p><\/li>

                          • Try to use custom metrics only. External metrics API can provide access to a large number of metrics which constitutes a security risk. If compromised, a custom metrics API is less risky, since it only holds your specific metrics.<\/span><\/span>

                            \u00a0<\/p><\/li>

                          • By using HPA together with Cluster Autoscaler (CA) you can coordinate scalability of pods with the behavior of nodes in the cluster. This way, the Cluster Autoscaler can add eligible nodes when you need to scale up and conversely, it can shut down unneeded nodes to conserve resources when scaling down.<\/span><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t\t
                            \n\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t
                            \n\t\t\t
                            <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t

                            3. Cluster Autoscaler (CA)<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t\t
                            \n\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t\t\t

                            The Cluster Autoscaler automatically adds or removes nodes in a cluster based on resource requests from pods in order to provide the right amount of computing resources needed to host the desired workloads.<\/span><\/p>

                            \u00a0<\/p>

                            Unlike the HPA and VPA, this autoscaler does not deal with application autoscaling but with autoscaling the number of worker nodes in a Kubernetes cluster as the usage fluctuates. The cluster autoscaler <\/span>changes <\/b>the number of <\/span>cluster nodes<\/b>, while HPA <\/span>scales <\/b>the number of <\/span>running cluster pods<\/b>.<\/span><\/p>

                            To make a decision, the Cluster Autoscaler checks every 10 seconds to detect pods that could be a pending state. It does not measure CPU and memory usage values directly. The CA adds nodes to accommodate unscheduled pods, and removes nodes when they are not being used.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

                            \n\t\t\t\t\t\t
                            \n\t\t\t\t\t
                            \n\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t
                            \n\t\t\t
                            <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t

                            How CA works<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t\t
                            \n\t\t\t
                            \n\t\t\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t\t\t

                            A pod becomes unschedulable (Pending) when the Kubernetes scheduler is unable to find a node that can accommodate the pod. Whenever a kubernetes scheduler fails to find a place to run a pod it sets “schedulable” PodCondition to false and reason to “unschedulable”. For instance when a pod requests more CPU than is available on any of the cluster nodes.\u00a0<\/span><\/p>

                            Cluster autoscaler works in a loop looking for unschedulable pods and attempting to consolidate pods that are currently deployed on only a few nodes.\u00a0<\/span><\/p>

                            When there are not enough resources and the number of unschedulable pods increases, the CA automatically adds additional nodes to the cluster. Conversely, the CA can merge pods onto fewer nodes to free up a node and terminate it.<\/span><\/p>

                            Here is how the CA scales up a cluster:<\/span><\/p>

                            1. The CA checks for pending pods with a default scan interval of 10 seconds (configurable with the scan-interval flag).<\/span><\/li>
                            2. If unschedulable pods are foung and the cluster needs more resources, CA launches a new node (minding the limits on max number of nodes).<\/span><\/li>
                            3. Kubernetes registers the newly provisioned node with the control plane to make it available to the Kubernetes scheduler for assigning pods.<\/span><\/li>
                            4. Kubernetes scheduler allocates the pending pods to the new node.<\/span><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                              \n\t\t\t\t\t\t
                              \n\t\t\t\t\t
                              \n\t\t\t
                              \n\t\t\t\t\t\t
                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t
                              \n\t\t\t
                              <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                              \n\t\t\t\t
                              \n\t\t\t\t\t

                              Best Practices<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                              \n\t\t\t\t\t\t
                              \n\t\t\t\t\t
                              \n\t\t\t
                              \n\t\t\t\t\t\t
                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t\t\t