Rewording Cluster Autoscaling paragraph in the last blog (#73)

* Update 2024-11-26-in-kubernetes-we-trust.adoc * Update _posts/2024-11-26-in-kubernetes-we-trust.adoc Co-authored-by: David Kwon <[email protected]> --------- Co-authored-by: David Kwon <[email protected]>
eclipse-che · Dec 3, 2024 · e8486fb · e8486fb
1 parent b3ce2d0
commit e8486fb
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/_posts/2024-11-26-in-kubernetes-we-trust.adoc b/_posts/2024-11-26-in-kubernetes-we-trust.adoc
@@ -71,9 +71,9 @@ attributes:
   controller.devfile.io/storage-type: ephemeral
 ....
 
-=== Autoscaling
+=== Cluster Autoscaling
 
-Although autoscaling is a powerful Kubernetes feature, you cannot always fall back on it, and should always consider predictive scaling by analyzing the load data on your environment to detect daily or weekly usage patterns. If your workloads follow some pattern, e.g. there are huge spikes based on the time of the day, you should consider provisioning worker nodes in advance (e.g. a lot of users turn on their smart speakers in the morning between 7 - 9 am, and there is a huge spike in the requests that on the infrastructure level is predicted and handled in advance).
+Although link:https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/[Cluster Autoscaling] is a powerful Kubernetes feature, you cannot always fall back on it and should always consider predictive scaling by analyzing load data on your environment to detect daily or weekly usage patterns. If your workloads follow a pattern and there are dramatic peaks throughout the day you should consider provisioning worker nodes accordingly (e.g. a lot of users turn on their smart speakers in the morning between 7 - 9 a.m. causing a huge spike in requests that can be predicted and handled in advance on the infrastructure level).
 
 === CPU Limits