HA is enabled for Autoscaler too (knative#3192)

* HA is enabled for Autoscaler too

* Update docs/serving/config-ha.md

Co-authored-by: Victor Agababov <vagababov@gmail.com>

* Update docs/serving/config-ha.md

Co-authored-by: Victor Agababov <vagababov@gmail.com>

* Update docs/serving/config-ha.md

Co-authored-by: Victor Agababov <vagababov@gmail.com>

* rephase

* reword

* Update docs/serving/config-ha.md

Co-authored-by: Ashleigh Brennan <40172997+abrennan89@users.noreply.github.com>

* remove

* Update docs/serving/config-ha.md

Co-authored-by: Ashleigh Brennan <40172997+abrennan89@users.noreply.github.com>

Co-authored-by: Victor Agababov <vagababov@gmail.com>
Co-authored-by: Ashleigh Brennan <40172997+abrennan89@users.noreply.github.com>

Author: 3 people

docs/serving/config-ha.md

@@ -6,11 +6,10 @@ type: "docs"
 
 Active/passive high availability (HA) is a standard feature of Kubernetes APIs that helps to ensure that APIs stay operational if a disruption occurs. In an HA deployment, if an active controller crashes or is deleted, another controller is available to take over processing of the APIs that were being serviced by the controller that is now unavailable.
 
-Active/passive HA in Knative is available through leader election, which can be enabled after Knative Serving control plane is installed.
-
 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 for the `autoscaler` component.
+Leader election is enabled by default for all Knative Serving components.
+HA functionality is disabled by default for all Knative Serving components, which are configured with only one replica.
 
 ## Disabling leader election
 
@@ -27,8 +26,8 @@ $ kubectl -n knative-serving scale deployment <deployment-name> --replicas=2
 - Setting `--replicas` to a value of `2` enables HA.
 - 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.
 
+**NOTE:** If you scale down the `autoscaler` component, you may observe inaccurate autoscaling results for some revisions for a period of time up to the `stable-window` value. This is because when an `autoscaler` pod is terminating, ownership of the revisions belonging to that pod is passed to other `autoscaler` pods that are on stand by. The `autoscaler` pods that take over ownership of those revisions use the `stable-window` time to build the scaling metrics state for those revisions.
 
 ## Scaling the data plane
 
@@ -54,4 +53,3 @@ $ kubectl patch hpa activator -n knative-serving -p '{"spec":{"minReplicas":9,"m
 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.
-