Merge pull request #29018 from SamWheating/sw-fix-sentence-in-hpa-docs

Fixing improper sentence in HPA documentation

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -198,14 +198,17 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe
 
 ## Autoscaling during rolling update
 
-Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you.
+Kubernetes lets you perform a rolling update on a Deployment. In that
-Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
+case, the Deployment manages the underlying ReplicaSets for you.
-it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
+When you configure autoscaling for a Deployment, you bind a
+HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler
+manages the `replicas` field of the Deployment. The deployment controller is responsible
+for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable
+number during the rollout and also afterwards.
 
-Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
+If you perform a rolling update of a StatefulSet that has an autoscaled number of
-i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
+replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
-The reason this doesn't work is that when rolling update creates a new replication controller,
+similar to ReplicaSet).
-the Horizontal Pod Autoscaler will not be bound to the new replication controller.
 
 ## Support for cooldown/delay