Raising the Load and Observing Autoscaler Behavior

$ kubectl get hpa NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE php-apache Deployment/php-apache/scale 50% 0% 1 20 14s ``` Please note that the current CPU consumption is 0% as we are not sending any requests to the server (the CURRENT column shows the average across all the pods controlled by the corresponding replication controller). #### Raising the Load Now, we will see how our autoscalers (Cluster Autoscaler and Horizontal Pod Autoscaler) react on the increased load of the server. We will start two infinite loops of queries to our server (please run them in different terminals): ``` $ kubectl run -i --tty load-generator --image=busybox /bin/sh Hit enter for command prompt $ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done ``` We need to wait a moment (about one minute) for stats to propagate. Afterwards, we will examine status of Horizontal Pod Autoscaler: ``` $ kubectl get hpa NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE php-apache Deployment/php-apache/scale 50% 310% 1 20 2m $ kubectl get deployment php-apache NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE php-apache 7 7 7 3 4m ``` Horizontal Pod Autoscaler has increased the number of pods in our deployment to 7. Let’s now check, if all the pods are running: ``` jsz@jsz-desk2:~/k8s-src$ kubectl get pods php-apache-2046965998-3ewo6 0/1 Pending 0 1m php-apache-2046965998-8m03k 1/1 Running 0 1m php-apache-2046965998-ddpgp 1/1 Running 0 5m php-apache-2046965998-lrik6 1/1 Running 0 1m php-apache-2046965998-nj465 0/1 Pending 0 1m php-apache-2046965998-tmwg1 1/1 Running 0 1m php-apache-2046965998-xkbw1 0/1 Pending 0 1m ``` As we can see, some pods are pending. Let’s describe one of pending pods to get the reason of the pending state: ``` $ kubectl describe pod php-apache-2046965998-3ewo6 Name: php-apache-2046965998-3ewo6 Namespace: default ... Events: FirstSeen From SubobjectPath Type Reason Message 1m {default-scheduler } Warning FailedScheduling pod (php-apache-2046965998-3ewo6) failed to fit in any node fit failure on node (kubernetes-minion-group-yhdx): Insufficient CPU fit failure on node (kubernetes-minion-group-de5q): Insufficient CPU 1m {cluster-autoscaler } Normal TriggeredScaleUp pod triggered scale-up, mig: kubernetes-minion-group, sizes (current/new): 2/3 ``` The pod is pending as there was no CPU in the system for it. We see there’s a TriggeredScaleUp event connected with the pod. It means that the pod triggered reaction of Cluster Autoscaler and a new node will be added to the cluster. Now we’ll wait for the reaction (about 3 minutes) and list all nodes: ``` $ kubectl get nodes NAME STATUS AGE kubernetes-master Ready,SchedulingDisabled 9m kubernetes-minion-group-6z5i Ready 43s kubernetes-minion-group-de5q Ready 9m

This section focuses on observing how the Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler react to an increased load on the PHP-Apache server. It initiates infinite loops of queries to the server to simulate a high load. The section then checks the status of the HPA, confirming that it increases the number of pods in response to the load. It also examines the state of the pods, identifies pending pods due to insufficient CPU resources, and highlights how this triggers the Cluster Autoscaler to add a new node to the cluster.