Cluster autoscaler example
2973 Ansichten
15.03.2024 
Cloud / Managed Kubernetes Service
OVHcloud Managed Kubernetes service provides you Kubernetes clusters without the hassle of installing or operating them.
During the day-to-day life of your cluster, you may want to dynamically adjust the size of your cluster to accommodate to your workloads. The cluster autoscaler simplifies the task by scaling up or down your OVHcloud Managed Kubernetes cluster to meet the demand of your workloads.
Before you begin
This tutorial assumes that you already have a working OVHcloud Managed Kubernetes cluster, and some basic knowledge of how to operate it. If you want to know more on those topics, please look at the OVHcloud Managed Kubernetes Service Quickstart.
It also assumes that you have read the Using the cluster autoscaler guide.
Enabling the autoscaling on the node pool
The easiest way to enable the autoscaler is using the Kubernetes API, for example using kubectl.
As explained in the How nodes and node pools work guide, in your OVHcloud Managed Kubernetes cluster, nodes are grouped in node pools (groups of nodes sharing the same configuration).
Autoscale is configured on a node pool basis, i.e. you don't enable autoscaling on a full cluster, you enable it for one or more of your node pools.
You can activate the autoscaler on several node pools, each of which can have a different type of instance as well as different min and max nodes number limits.
In order to avoid unexpected expenses, you should be careful to not enable autoscaling on monthly-billed node pools. However, you are still allowed to do so if you know what you are doing.
A common configuration is to use non-autoscaled, monthly-billed node pools as base for your static workload, and autoscaled, hourly-billed node pools with smaller flavors for your dynamic workload.
The source code of the following example is available in the public Github repository public-cloud-examples
When you create your cluster, you can bootstrap a default node pool in it, and you can add others in the Public Cloud section of the OVHcloud Control Panel or directly using the Kubernetes API.
Deploying a test workload
Let's assume that you have created an MKS cluster with a node pool with its minimum set to 1 and its maximum set to 3.
In order to test the autoscaler, we offer you to install a Python heavy CPU load Deployment that deploys several instances of Python CPU load pods. The Python CPU load pod's goal is to consume all the CPU allocated to it. It's a CPU intensive operation but it uses a minimal amount of memory.
Create a cpu-load.yaml manifest for the python-cpu-load deployment:
As you can see, we will begin by deploying 3 replicas of the pod. Each replica consumes 150m CPU (0.150 CPUs), and we are using D2-4 instances, with 2000m CPU (2 CPU cores). In the tutorial we will increase the number of replicas to 12 then to 24, to see how the autoscaler grows up the node pool to 2 then to 3 nodes.
Deploy the CPU load deployment:
In my example cluster, we deploy the simple workload, and we verify that we still have only one node in the cluster.
Scaling up the workload
Now we can set the relicas number to 12, that should be enough to activate the scaling up of the node pool.
As you can see then with kubectl get nodepools, the autoscaler detects capacity has been reached and asks for a new node:
And in a few moments, the new node is created and active, and all the pods are running:
The scaling-up works as intended!
If now we ask the deployment to have 24 replicas:
The autoscaler will detect nodes in Pending and add a third node:
Scaling down
Let's scale down the deployment again to go back to 3 replicas:
In a few moments, only three pods will remain:
The autoscaler will detect that the nodes are under the value scale-down-utilization-threshold parameter (the node utilization level, defined as sum of requested resources divided by capacity, below which a node can be considered for scale down, by default 0.5), and marks the nodes 2 and 3 as unneeded.
After some minutes according to the value of scale-down-unneeded-time (parameter that sets how long a node should be unneeded before it is eligible for scale down, 10 minutes by default), the node will be deleted and the cluster will be scaled down.
After 10 minutes we are back to 2 nodes:
And 10 minutes later, we have only one node:
Cleaning up
To clean up your cluster, simply delete your python-cpu-load deployment:
Conclusion
In this tutorial we have seen how to enable the autoscaler on a node pool on your OVHcloud Managed Kubernetes cluster, and how to use an example workload to test how it works.
Go further
To have an overview of OVHcloud Managed Kubernetes service, you can go to the OVHcloud Managed Kubernetes page.
Otherwise to skip it and learn more about using your Kubernetes cluster the practical way, we invite you to look at our tutorials.
-
If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project.
-
Join our community of users.
How to manage nodes and node pools on an OVHcloud Managed Kubernetes cluster
392