From 917ae497eb614e35c17c749bbb0ef9c5e04fe30c Mon Sep 17 00:00:00 2001 From: Irfan Ur Rehman Date: Sat, 16 Sep 2017 01:12:51 +0530 Subject: [PATCH 1/4] Federated Hpa feature doc --- _data/tasks.yml | 1 + .../cluster-administration/federation.md | 1 + docs/tasks/administer-federation/hpa.md | 154 ++++++++++++++++++ 3 files changed, 156 insertions(+) create mode 100644 docs/tasks/administer-federation/hpa.md diff --git a/_data/tasks.yml b/_data/tasks.yml index a2d71d5fece10..01ee084713c8c 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -173,6 +173,7 @@ toc: - docs/tasks/administer-federation/daemonset.md - docs/tasks/administer-federation/deployment.md - docs/tasks/administer-federation/events.md + - docs/tasks/administer-federation/hpa.md - docs/tasks/administer-federation/ingress.md - docs/tasks/administer-federation/namespaces.md - docs/tasks/administer-federation/replicaset.md diff --git a/docs/concepts/cluster-administration/federation.md b/docs/concepts/cluster-administration/federation.md index cf1d2aba4dc1a..4c37cbdea8a2c 100644 --- a/docs/concepts/cluster-administration/federation.md +++ b/docs/concepts/cluster-administration/federation.md @@ -91,6 +91,7 @@ The following guides explain some of the resources in detail: * [DaemonSets](/docs/tasks/administer-federation/daemonset/) * [Deployment](/docs/tasks/administer-federation/deployment/) * [Events](/docs/tasks/administer-federation/events/) +* [Hpa](/docs/tasks/administer-federation/hpa/) * [Ingress](/docs/tasks/administer-federation/ingress/) * [Namespaces](/docs/tasks/administer-federation/namespaces/) * [ReplicaSets](/docs/tasks/administer-federation/replicaset/) diff --git a/docs/tasks/administer-federation/hpa.md b/docs/tasks/administer-federation/hpa.md new file mode 100644 index 0000000000000..d1566a0a86961 --- /dev/null +++ b/docs/tasks/administer-federation/hpa.md @@ -0,0 +1,154 @@ +--- +title: Federated Hpas +--- + +{% capture overview %} +This guide explains how to use Hpas in the Federation control plane. + +Hpas in the federation control plane (referred to as "federated Hpas" in +this guide) are very similar to the traditional [Kubernetes +Hpas](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality. +Creating a hpa targeting a federated object in the federation control plane ensures that the +desired number of replicas of the target object are scaled across the registered clusters, +instead of a single cluster. Further the control plane keeps monitoring the status of each +individual hpa in the federated clusters and ensures the workload replicas move where they are +needed most by manipulating the min and max limits of the hpa objects into the federated clusters. +{% endcapture %} + +{% capture prerequisites %} + +* {% include federated-task-tutorial-prereqs.md %} +* You are also expected to have a basic +[working knowledge of Kubernetes](/docs/getting-started-guides/) in +general and [Hpas](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular. + +The federated hpa is an alpha feature as of now and the API is not enabled by default on the +federated apiserver. To use this feature the user or the admin deploying the federation control +plane will need to run the federated apiserver with option `--runtime-config=api/all=true` to +enable all apis, including alpha apis. Additionally the federated hpa as of now can work only +when used with cpuUtilization metrics. +{% endcapture %} + +{% capture steps %} + +## Creating a Federated Hpa + +The API for Federated Hpa is 100% compatible with the +API for traditional Kubernetes Hpa. You can create an Hpa by sending +a request to the federation apiserver. + +You can do that using [kubectl](/docs/user-guide/kubectl/) by running: + +``` shell +cat < Date: Mon, 18 Sep 2017 01:36:59 +0530 Subject: [PATCH 2/4] Federated Hpa feature doc review fixes --- docs/tasks/administer-federation/hpa.md | 123 ++++++++++++++---------- 1 file changed, 74 insertions(+), 49 deletions(-) diff --git a/docs/tasks/administer-federation/hpa.md b/docs/tasks/administer-federation/hpa.md index d1566a0a86961..81458fcba8a1c 100644 --- a/docs/tasks/administer-federation/hpa.md +++ b/docs/tasks/administer-federation/hpa.md @@ -1,18 +1,18 @@ --- -title: Federated Hpas +title: Federated Federated Horizontal Pod Autoscalers (HPA) --- {% capture overview %} This guide explains how to use Hpas in the Federation control plane. -Hpas in the federation control plane (referred to as "federated Hpas" in +HPAs in the federation control plane (referred to as "federated HPAs" in this guide) are very similar to the traditional [Kubernetes -Hpas](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality. -Creating a hpa targeting a federated object in the federation control plane ensures that the +HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality. +Creating a HPA targeting a federated object in the federation control plane ensures that the desired number of replicas of the target object are scaled across the registered clusters, instead of a single cluster. Further the control plane keeps monitoring the status of each -individual hpa in the federated clusters and ensures the workload replicas move where they are -needed most by manipulating the min and max limits of the hpa objects into the federated clusters. +individual HPA in the federated clusters and ensures the workload replicas move where they are +needed most by manipulating the min and max limits of the HPA objects into the federated clusters. {% endcapture %} {% capture prerequisites %} @@ -20,21 +20,21 @@ needed most by manipulating the min and max limits of the hpa objects into the f * {% include federated-task-tutorial-prereqs.md %} * You are also expected to have a basic [working knowledge of Kubernetes](/docs/getting-started-guides/) in -general and [Hpas](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular. +general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular. -The federated hpa is an alpha feature as of now and the API is not enabled by default on the +The federated HPA is an alpha feature as of now and the API is not enabled by default on the federated apiserver. To use this feature the user or the admin deploying the federation control plane will need to run the federated apiserver with option `--runtime-config=api/all=true` to -enable all apis, including alpha apis. Additionally the federated hpa as of now can work only +enable all apis, including alpha apis. Additionally the federated HPA as of now can work only when used with cpuUtilization metrics. {% endcapture %} {% capture steps %} -## Creating a Federated Hpa +## Creating a Federated HPA -The API for Federated Hpa is 100% compatible with the -API for traditional Kubernetes Hpa. You can create an Hpa by sending +The API for Federated HPA is 100% compatible with the +API for traditional Kubernetes HPA. You can create an HPA by sending a request to the federation apiserver. You can do that using [kubectl](/docs/user-guide/kubectl/) by running: @@ -61,92 +61,117 @@ The '--context=federation-cluster' flag tells kubectl to submit the request to the Federation apiserver instead of sending it to a Kubernetes cluster. -Once a federated Hpa is created, the federation control plane will partition and -create an Hpa in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: +Once a federated HPA is created, the federation control plane will partition and +create this HPA in all underlying Kubernetes clusters. As of `kubernetes V1.7` +[cluster selectors](docs/tasks/administer-federation/cluster/#clusterselector-annotation) +can also be used to restrict any federated object, including the HPAs into a subset +of clusters. +You can verify the creation by checking each of the underlying clusters, for example: ``` shell -kubectl --context=gce-asia-east1a get hpa php-apache +kubectl --context=gce-asia-east1a get HPA php-apache ``` The above assumes that you have a context named 'gce-asia-east1a' configured in your client for your cluster in that zone. -The Hpa in the underlying clusters will match the federation Hpa +The HPA in the underlying clusters will match the federation HPA except in the number of min and max replicas. The federation control plane will ensure that the sum of max replicas in each cluster matches the specified -max replicas on the federated hpa object and sum of min replicas will be greater -then or equal to the min specified on the federated hpa object. The sum of min -is greater or equal to specified min because an Hpa into a particular cluster -cannot have a min replica as 0. +max replicas on the federated HPA object and sum of min replicas will be greater +than or equal to the min specified on the federated HPA object. The sum of min +is greater than or equal to specified min because an HPA into a particular +cluster cannot have a min replica as 0. -### Spreading Hpa min and max replicas in Underlying Clusters +### Spreading HPA min and max replicas in Underlying Clusters By default, first max replicas are spread equally in all the underlying clusters and then min replicas are distributed to those clusters which got max. This means -that each cluster will get an hpa if the max replicas specified are greater then +that each cluster will get an HPA if the specified max replicas are greater than the total clusters participating in this federation and some clusters will be -skipped if max replicas specified are lesser then the total clusters participating +skipped if specified max replicas are lesser than the total clusters participating in this federation. For example: -if you have 3 registered clusters and you create a federated Hpa with -`spec.maxReplicas = 9`, and `spec.minReplicas = 2` then each Hpa in the 3 clusters +if you have 3 registered clusters and you create a federated HPA with +`spec.maxReplicas = 9`, and `spec.minReplicas = 2` then each HPA in the 3 clusters will get `spec.maxReplicas=3` and `spec.minReplicas = 1`. -Its worth noting that the minimum number of minReplicas on an Hpa cannot be zero. -Currently the default distribution is only available on the federated hpa, but in +Its worth noting that the minimum number of minReplicas on an HPA cannot be zero. +Currently the default distribution is only available on the federated HPA, but in future users preferences could also be specified to control and/or restrict this distribution. ## Updating a Federated ReplicaSet -You can update a federated Hpa as you would update a Kubernetes -Hpa; however, for a federated Hpa, you must send the request to +You can update a federated HPA as you would update a Kubernetes +HPA; however, for a federated HPA, you must send the request to the federation apiserver instead of sending it to a specific Kubernetes cluster. -The Federation control plane ensures that whenever the federated Hpa is -updated, it updates the corresponding Hpa in all underlying clusters to +The Federation control plane ensures that whenever the federated HPA is +updated, it updates the corresponding HPA in all underlying clusters to match it. If your update includes a change in number of replicas, the federation control plane will change the number of replicas in underlying clusters to ensure that the sum of the max and min replica remains matched as specified in the previous section above. -## Deleting a Federated Hpa +## Deleting a Federated HPA -You can delete a federated Hpa as you would delete a Kubernetes -Hpa; however, for a federated Hpa, you must send the request to +You can delete a federated HPA as you would delete a Kubernetes +HPA; however, for a federated HPA, you must send the request to the federation apiserver instead of sending it to a specific Kubernetes cluster. +It should also be noted that for the federated resource to be deleted from +all underlying clusters, [cascading deletion](docs/concepts/cluster-administration/federation/#cascading-deletion) +should be used. For example, you can do that using kubectl by running: ```shell -kubectl --context=federation-cluster delete hpa php-apache +kubectl --context=federation-cluster delete HPA php-apache ``` -## Alternative ways to use federated Hpa +## Alternative ways to use federated HPA To a `federation user` interacting with federated control plane (or simply federation), -the interaction is same as interacting with a normal k8s cluster (but with a limited set of -apis, that which are federated). As both deployments and horizontalpodautoscalers are -now federated, `kubectl` commands like `kubectl run` and `kubectl autoscale` work on -federation. Given this fact the mechanism specified in +the interaction is almost identical as interacting with a normal k8s cluster (but +with a limited set of APIs that are federated). As both deployments and +horizontalpodautoscalers are now federated, `kubectl` commands like `kubectl run` +and `kubectl autoscale` work on federation. Given this fact the mechanism specified in [horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) will also work when used with federation. Care however will need to be taken that when -{generating load on a target deployment](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load) +[generating load on a target deployment](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load) it should be done against a specific federated cluster (or multiple clusters) not the federation. ## Conclusion -The use of federated hpa is to ensure workload replicas move to the cluster(s) where -they are needed most, or in other words where the load is more. Federated hpa feature -achieves this by manipulating the min and max replicas on the hpas it creates in the -federated clusters. It reduces the max and min replicas from those clusters which does -not see load or needed cpu utilization on the target workload and increases the same -on the hpa in those clusters where the target workload is more loaded or sees higher -cpu utilization. [Federated hpa proposal](https://github.com/kubernetes/community/pull/593) +The use of federated HPA is to ensure workload replicas move to the cluster(s) where +they are needed most, or in other words where the load is beyond expected threshold. +Federated HPA feature achieves this by manipulating the min and max replicas on the +HPAs it creates in the federated clusters. It does not directly monitor the target +object metrics from the federated clusters. It actually relies on the in cluster HPA +controllers to monitor the metrics and update relevant fields. The in cluster HPA +controller monitors the target pod metrics and updates the fields like desired +replicas (after metrics based calculations) and current replicas (observing the +current status of in cluster pods). The federate HPA controller on the other hand +monitors only the cluster specific HPA object fields and updates the min replica and +max replica fields of those in cluster HPA objects which have replicas matching thresholds. + +For example: +The cluster which has both desired replicas and current replicas same as the max replicas +and averaged current cpu utilization still higher than the target cpu utilization (all of which +are fields on local HPA object) would mean that the target app in this particular cluster +needs more replicas, and the scaling is currently restricted by max replicas set on this local +HPA object. In such a scenario, the federated HPA controller scans all clusters and tries to +find clusters which do not have such a condition (meaning the the desired replicas are lesser +than the max and current averaged cpu utilization is lower then the threshold). If it finds such +a cluster, it reduces the max replica on the HPA in this cluster and increases the max replicas +on the HPA in the cluster which needed the replicas. +There are many other similar conditions which federated HPA controller checks and moves the max +replicas and min replicas around the local HPAs in federated clusters to eventually ensure, that +the replicas move (or remain) in the cluster(s) which need them. +For a more curious reader [federated HPA design proposal](https://github.com/kubernetes/community/pull/593) can be checked for more details. {% endcapture %} From e52e6a11825221ad2b4c25a99faee8c8e0b3e566 Mon Sep 17 00:00:00 2001 From: Zach Corleissen Date: Mon, 18 Sep 2017 22:16:30 -0500 Subject: [PATCH 3/4] Update hpa.md --- docs/tasks/administer-federation/hpa.md | 79 ++++++++++++------------- 1 file changed, 37 insertions(+), 42 deletions(-) diff --git a/docs/tasks/administer-federation/hpa.md b/docs/tasks/administer-federation/hpa.md index 81458fcba8a1c..a2139513231c4 100644 --- a/docs/tasks/administer-federation/hpa.md +++ b/docs/tasks/administer-federation/hpa.md @@ -1,16 +1,15 @@ --- -title: Federated Federated Horizontal Pod Autoscalers (HPA) +title: Federated horizontal pod autoscalers (HPA) --- {% capture overview %} -This guide explains how to use Hpas in the Federation control plane. +This guide explains how to use federated horizontal pod autoscalers (HPAs) in the federation control plane. -HPAs in the federation control plane (referred to as "federated HPAs" in -this guide) are very similar to the traditional [Kubernetes +HPAs in the federation control plane are similar to the traditional [Kubernetes HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality. Creating a HPA targeting a federated object in the federation control plane ensures that the desired number of replicas of the target object are scaled across the registered clusters, -instead of a single cluster. Further the control plane keeps monitoring the status of each +instead of a single cluster. Also, the control plane keeps monitoring the status of each individual HPA in the federated clusters and ensures the workload replicas move where they are needed most by manipulating the min and max limits of the HPA objects into the federated clusters. {% endcapture %} @@ -22,24 +21,24 @@ needed most by manipulating the min and max limits of the HPA objects into the f [working knowledge of Kubernetes](/docs/getting-started-guides/) in general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular. -The federated HPA is an alpha feature as of now and the API is not enabled by default on the -federated apiserver. To use this feature the user or the admin deploying the federation control -plane will need to run the federated apiserver with option `--runtime-config=api/all=true` to -enable all apis, including alpha apis. Additionally the federated HPA as of now can work only -when used with cpuUtilization metrics. +The federated HPA is an alpha feature. The API is not enabled by default on the +federated apiserver. To use this feature, the user or the admin deploying the federation control +plane needs to run the federated apiserver with option `--runtime-config=api/all=true` to +enable all APIs, including alpha APIs. Additionally, the federated HPA only works +when used with CPU utilization metrics. {% endcapture %} {% capture steps %} ## Creating a Federated HPA -The API for Federated HPA is 100% compatible with the +The API for federated HPAs is 100% compatible with the API for traditional Kubernetes HPA. You can create an HPA by sending a request to the federation apiserver. -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: +You can do that with [kubectl](/docs/user-guide/kubectl/) by running: -``` shell +```shell cat < Date: Fri, 22 Sep 2017 16:08:49 -0700 Subject: [PATCH 4/4] Update hpa.md --- docs/tasks/administer-federation/hpa.md | 83 +++++++++++++------------ 1 file changed, 43 insertions(+), 40 deletions(-) diff --git a/docs/tasks/administer-federation/hpa.md b/docs/tasks/administer-federation/hpa.md index a2139513231c4..ae1dfb6448781 100644 --- a/docs/tasks/administer-federation/hpa.md +++ b/docs/tasks/administer-federation/hpa.md @@ -1,17 +1,20 @@ --- -title: Federated horizontal pod autoscalers (HPA) +title: Federated Horizontal Pod Autoscalers (HPA) --- {% capture overview %} + +{% include feature-state-alpha.md %} + This guide explains how to use federated horizontal pod autoscalers (HPAs) in the federation control plane. HPAs in the federation control plane are similar to the traditional [Kubernetes HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality. -Creating a HPA targeting a federated object in the federation control plane ensures that the +Creating an HPA targeting a federated object in the federation control plane ensures that the desired number of replicas of the target object are scaled across the registered clusters, instead of a single cluster. Also, the control plane keeps monitoring the status of each individual HPA in the federated clusters and ensures the workload replicas move where they are -needed most by manipulating the min and max limits of the HPA objects into the federated clusters. +needed most by manipulating the min and max limits of the HPA objects in the federated clusters. {% endcapture %} {% capture prerequisites %} @@ -22,19 +25,19 @@ needed most by manipulating the min and max limits of the HPA objects into the f general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular. The federated HPA is an alpha feature. The API is not enabled by default on the -federated apiserver. To use this feature, the user or the admin deploying the federation control -plane needs to run the federated apiserver with option `--runtime-config=api/all=true` to +federated API server. To use this feature, the user or the admin deploying the federation control +plane needs to run the federated API server with option `--runtime-config=api/all=true` to enable all APIs, including alpha APIs. Additionally, the federated HPA only works when used with CPU utilization metrics. {% endcapture %} {% capture steps %} -## Creating a Federated HPA +## Creating a federated HPA The API for federated HPAs is 100% compatible with the API for traditional Kubernetes HPA. You can create an HPA by sending -a request to the federation apiserver. +a request to the federation API server. You can do that with [kubectl](/docs/user-guide/kubectl/) by running: @@ -56,17 +59,17 @@ spec: EOF ``` -The '--context=federation-cluster' flag tells kubectl to submit the +The `--context=federation-cluster` flag tells `kubectl` to submit the request to the federation API server instead of sending it to a Kubernetes cluster. Once a federated HPA is created, the federation control plane partitions and -creates the HPA in all underlying Kubernetes clusters. As of `kubernetes V1.7` +creates the HPA in all underlying Kubernetes clusters. As of Kubernetes V1.7, [cluster selectors](docs/tasks/administer-federation/cluster/#clusterselector-annotation) -can also be used to restrict any federated object, including the HPAs into a subset +can also be used to restrict any federated object, including the HPAs in a subset of clusters. -You can verify the creation by checking each of the underlying clusters. For example, with a context named 'gce-asia-east1a' +You can verify the creation by checking each of the underlying clusters. For example, with a context named `gce-asia-east1a` configured in your client for your cluster in that zone: ```shell @@ -86,41 +89,41 @@ than or equal to the minimum specified on the federated HPA object. By default, first max replicas are spread equally in all the underlying clusters, then min replicas are distributed to those clusters that received their maximum value. This means that each cluster will get an HPA if the specified max replicas are greater than the total clusters participating in this federation, and some clusters will be -skipped if specified max replicas are lesser than the total clusters participating -in this federation. +skipped if specified max replicas are less than the total clusters participating +in the federation. For example: if you have 3 registered clusters and you create a federated HPA with `spec.maxReplicas = 9`, and `spec.minReplicas = 2`, then each HPA in the 3 clusters will get `spec.maxReplicas=3` and `spec.minReplicas = 1`. -Currently the default distribution is only available on the federated HPA, but in -future users preferences could also be specified to control and/or restrict this +Currently the default distribution is only available on the federated HPA, but in the +future, users preferences could also be specified to control and/or restrict this distribution. ## Updating a federated ReplicaSet You can update a federated HPA as you would update a Kubernetes HPA; however, for a federated HPA, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. +the federation API server instead of sending it to a specific Kubernetes cluster. The Federation control plane ensures that whenever the federated HPA is updated, it updates the corresponding HPA in all underlying clusters to match it. -If your update includes a change in number of replicas, the federation +If your update includes a change in the number of replicas, the federation control plane will change the number of replicas in underlying clusters to -ensure that the sum of the max and min replica remains matched as specified -in the previous section above. +ensure that the sum of the max and min replicas remains matched as specified +in the previous section. -## Deleting a Federated HPA +## Deleting a federated HPA You can delete a federated HPA as you would delete a Kubernetes HPA; however, for a federated HPA, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. +the federation API server instead of sending it to a specific Kubernetes cluster. It should also be noted that for the federated resource to be deleted from all underlying clusters, [cascading deletion](docs/concepts/cluster-administration/federation/#cascading-deletion) should be used. -For example, you can do that using kubectl by running: +For example, you can do that using `kubectl` by running: ```shell kubectl --context=federation-cluster delete HPA php-apache @@ -128,43 +131,43 @@ kubectl --context=federation-cluster delete HPA php-apache ## Alternative ways to use federated HPA -To a `federation user` interacting with federated control plane (or simply federation), -the interaction is almost identical as interacting with a normal k8s cluster (but -with a limited set of APIs that are federated). As both deployments and -horizontalpodautoscalers are now federated, `kubectl` commands like `kubectl run` -and `kubectl autoscale` work on federation. Given this fact the mechanism specified in +To a federation user interacting with federated control plane (or simply federation), +the interaction is almost identical to interacting with a normal Kubernetes cluster (but +with a limited set of APIs that are federated). As both Deployments and +HorizontalPodAutoscalers are now federated, `kubectl` commands like `kubectl run` +and `kubectl autoscale` work on federation. Given this fact, the mechanism specified in [horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) will also work when used with federation. Care however will need to be taken that when -[generating load on a target deployment](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load) +[generating load on a target deployment](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load), it should be done against a specific federated cluster (or multiple clusters) not the federation. ## Conclusion The use of federated HPA is to ensure workload replicas move to the cluster(s) where they are needed most, or in other words where the load is beyond expected threshold. -Federated HPA feature achieves this by manipulating the min and max replicas on the +The federated HPA feature achieves this by manipulating the min and max replicas on the HPAs it creates in the federated clusters. It does not directly monitor the target -object metrics from the federated clusters. It actually relies on the in cluster HPA -controllers to monitor the metrics and update relevant fields. The in cluster HPA +object metrics from the federated clusters. It actually relies on the in-cluster HPA +controllers to monitor the metrics and update relevant fields. The in-cluster HPA controller monitors the target pod metrics and updates the fields like desired replicas (after metrics based calculations) and current replicas (observing the -current status of in cluster pods). The federate HPA controller on the other hand -monitors only the cluster specific HPA object fields and updates the min replica and -max replica fields of those in cluster HPA objects which have replicas matching thresholds. +current status of in cluster pods). The federated HPA controller, on the other hand, +monitors only the cluster-specific HPA object fields and updates the min replica and +max replica fields of those in cluster HPA objects, which have replicas matching thresholds. -For example: The cluster which has both desired replicas and current replicas same as the max replicas +For example, if a cluster has both desired replicas and current replicas the same as the max replicas, and averaged current CPU utilization still higher than the target CPU utilization (all of which -are fields on local HPA object) would mean that the target app in this particular cluster +are fields on local HPA object), then the target app in this cluster needs more replicas, and the scaling is currently restricted by max replicas set on this local HPA object. In such a scenario, the federated HPA controller scans all clusters and tries to -find clusters which do not have such a condition (meaning the the desired replicas are lesser -than the max and current averaged cpu utilization is lower then the threshold). If it finds such +find clusters which do not have such a condition (meaning the the desired replicas are less +than the max, and current averaged cpu utilization is lower then the threshold). If it finds such a cluster, it reduces the max replica on the HPA in this cluster and increases the max replicas on the HPA in the cluster which needed the replicas. -There are many other similar conditions which federated HPA controller checks and moves the max -replicas and min replicas around the local HPAs in federated clusters to eventually ensure, that +There are many other similar conditions which the federated HPA controller checks and moves the max +replicas and min replicas around the local HPAs in federated clusters to eventually ensure that the replicas move (or remain) in the cluster(s) which need them. For more information, see ["federated HPA design proposal"](https://github.com/kubernetes/community/pull/593).