Add info on throttling during cluster scale down

This commit adds information on how the scaling down the cluster
might take large amounts of time when the clusters are large/dense
as the nodes are drained in parallel amd the requests might get
throttled by the client.

Author: chaitanyaenr

modules/recommended-scale-practices.adoc

@@ -18,4 +18,15 @@ Cloud providers might implement a quota for API services. Therefore, gradually s
 
 The controller might not be able to create the machines if the replicas in the machine sets are set to higher numbers all at one time. The number of requests the cloud platform, which {product-title} is deployed on top of, is able to handle impacts the process. The controller will start to query more while trying to create, check, and update the machines with the status. The cloud platform on which {product-title} is deployed has API request limits and excessive queries might lead to machine creation failures due to cloud platform limitations.
 
-Enable machine health checks when scaling to large node counts. In case of failures, the health checks monitor the condition and automatically repair unhealthy machines.
+Enable machine health checks when scaling to large node counts. In case of failures, 
+the health checks monitor the condition and automatically repair unhealthy machines.
+
+[NOTE]
+====
+When scaling large and dense clusters to lower node counts, it might take large 
+amounts of time as the process involves draining or evicting the objects running on 
+the nodes being terminated in parallel. Also, the client might start to throttle the 
+requests if there are too many objects to evict. The default client QPS and burst 
+rates are currently set to `5` and `10` respectively and they cannot be modified 
+in {product-title}.
+====