Autoscaler can be scaled too now. Add correct docs for activator (#3189)

* Autoscaler can be scaled too now. Add docs for activator

- autoscaler can also be scaled now
- activator cannot be scaled by patching deployment, since there's an
  HPA that will snap it back to the HPA desired values
- thus, provide the correct commands to change the activator scale.

* nits

* spell

docs/serving/config-ha.md

@@ -10,7 +10,7 @@ Active/passive HA in Knative is available through leader election, which can be
 
 When using a leader election HA pattern, instances of controllers are already scheduled and running inside the cluster before they are required. These controller instances compete to use a shared resource, known as the leader election lock. The instance of the controller that has access to the leader election lock resource at any given time is referred to as the leader.
 
-HA functionality is enabled by default for all Knative Serving components except `autoscaler`.
+HA functionality is enabled by default for all Knative Serving components except for the `autoscaler` component.
 
 ## Disabling leader election
 
@@ -18,7 +18,7 @@ For components leveraging leader election to achieve HA, this capability can be
 
 ## Scaling the control plane
 
-With the notable exception of the `autoscaler` you can scale up any deployment running in `knative-serving` (or `kourier-system`) with a command like:
+With the exception of the `activator` component you can scale up any deployment running in `knative-serving` (or `kourier-system`) with a command like:
 
 ```
 $ kubectl -n knative-serving scale deployment <deployment-name> --replicas=2
@@ -28,3 +28,30 @@ $ kubectl -n knative-serving scale deployment <deployment-name> --replicas=2
 - You can use a higher value if you have a use case that requires more replicas of a deployment. For example, if you require a minimum of 3 `controller` deployments, set `--replicas=3`.
 - Setting `--replicas=1` disables HA.
 - Passing `--disable-ha` to the controller process disables leader election.
+
+
+## Scaling the data plane
+
+The scale of the `activator` component is governed by the Kubernetes HPA component. You can see the current HPA scale limits and the current scale by running:
+
+```
+$ kubectl get hpa activator -n knative-serving
+```
+
+The possible output will be something like:
+
+```
+NAME        REFERENCE              TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
+activator   Deployment/activator   2%/100%   5         15        11         346d
+```
+
+By default `minReplicas` and `maxReplicas` are set to `1` and `20`, correspondingly. If those values are not desirable for some reason, then, for example, you can change those values to `minScale=9` and `maxScale=19` using the following command:
+
+```
+$ kubectl patch hpa activator -n knative-serving -p '{"spec":{"minReplicas":9,"maxReplicas":19}}'
+```
+
+To set the activator scale to a particular value, just set `minScale` and `maxScale` to the same desired value.
+
+It is recommended for production deployments to run at least 3 `activator` instances for redundancy and avoiding single point of failure if a Knative service needs to be scaled from 0.
+