Load Reduction and Cluster Autoscaler Behavior

NAME READY STATUS RESTARTS AGE php-apache-2046965998-3ewo6 1/1 Running 0 3m php-apache-2046965998-8m03k 1/1 Running 0 3m php-apache-2046965998-ddpgp 1/1 Running 0 7m php-apache-2046965998-lrik6 1/1 Running 0 3m php-apache-2046965998-nj465 1/1 Running 0 3m php-apache-2046965998-tmwg1 1/1 Running 0 3m php-apache-2046965998-xkbw1 1/1 Running 0 3m ``` After the node addition all php-apache pods are running! #### Stop Load We will finish our example by stopping the user load. We’ll terminate both infinite while loops sending requests to the server and verify the result state: ``` $ kubectl get hpa NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE php-apache Deployment/php-apache/scale 50% 0% 1 10 16m $ kubectl get deployment php-apache NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE php-apache 1 1 1 1 14m ``` As we see, in the presented case CPU utilization dropped to 0, and the number of replicas dropped to 1. After deleting pods most of the cluster resources are unused. Scaling the cluster down may take more time than scaling up because Cluster Autoscaler makes sure that the node is really not needed so that short periods of inactivity (due to pod upgrade etc) won’t trigger node deletion (see [cluster autoscaler doc](https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/admin/cluster-management.md#cluster-autoscaling)). After approximately 10-12 minutes you can verify that the number of nodes in the cluster dropped: ``` $ kubectl get nodes NAME STATUS AGE kubernetes-master Ready,SchedulingDisabled 37m kubernetes-minion-group-de5q Ready 36m kubernetes-minion-group-yhdx Ready 36m ``` The number of nodes in our cluster is now two again as node kubernetes-minion-group-6z5i was removed by Cluster Autoscaler. ### Other use cases As we have shown, it is very easy to dynamically adjust the number of pods to the load using a combination of Horizontal Pod Autoscaler and Cluster Autoscaler. However Cluster Autoscaler alone can also be quite helpful whenever there are irregularities in the cluster load. For example, clusters related to development or continuous integration tests can be less needed on weekends or at night. Batch processing clusters may have periods when all jobs are over and the new will only start in couple hours. Having machines that do nothing is a waste of money. In all of these cases Cluster Autoscaler can reduce the number of unused nodes and give quite significant savings because you will only pay for these nodes that you actually need to run your pods. It also makes sure that you always have enough compute power to run your tasks.

This section focuses on what happens after the load is stopped. CPU utilization drops to 0%, and the number of pod replicas decreases to 1. The cluster scales down, removing unused nodes, although this process takes longer than scaling up due to Cluster Autoscaler's checks for sustained inactivity. The example concludes by highlighting other scenarios where Cluster Autoscaler is beneficial, such as development environments, CI/CD, and batch processing clusters, enabling cost savings by dynamically adjusting resources to match actual demand.