Merge pull request #91921 from prozehna/prozehna-nits-vpa

Nits on the VPA documentation

Author: mburke5678

modules/nodes-pods-vertical-autoscaler-about.adoc

@@ -23,7 +23,7 @@ You can use the default recommender or use your own alternative recommender to a
 
 The default recommender automatically computes historic and current CPU and memory usage for the containers in those pods and uses this data to determine optimized resource limits and requests to ensure that these pods are operating efficiently at all times. For example, the default recommender suggests reduced resources for pods that are requesting more resources than they are using and increased resources for pods that are not requesting enough.
 
-The VPA then automatically deletes any pods that are out of alignment with these recommendations one at a time, so that your applications can continue to serve requests with no downtime. The workload objects then re-deploy the pods with the original resource limits and requests. The VPA uses a mutating admission webhook to update the pods with optimized resource limits and requests before the pods are admitted to a node. If you do not want the VPA to delete pods, you can view the VPA resource limits and requests and manually update the pods as needed.
+The VPA then automatically deletes any pods that are out of alignment with these recommendations one at a time, so that your applications can continue to serve requests with no downtime. The workload objects then redeploy the pods with the original resource limits and requests. The VPA uses a mutating admission webhook to update the pods with optimized resource limits and requests before the pods are admitted to a node. If you do not want the VPA to delete pods, you can view the VPA resource limits and requests and manually update the pods as needed.
 
 [NOTE]
 ====
@@ -38,5 +38,5 @@ Administrators can use the VPA to better utilize cluster resources, such as prev
 
 [NOTE]
 ====
-If you stop running the VPA or delete a specific VPA CR in your cluster, the resource requests for the pods already modified by the VPA do not change. Any new pods get the resources defined in the workload object, not the previous recommendations made by the VPA.
+If you stop running the VPA or delete a specific VPA CR in your cluster, the resource requests for the pods already modified by the VPA do not change. However, any new pods get the resources defined in the workload object, not the previous recommendations made by the VPA.
 ====

modules/nodes-pods-vertical-autoscaler-custom.adoc

@@ -14,7 +14,7 @@ For example, the default recommender might not accurately predict future resourc
 
 [NOTE]
 ====
-Instructions for how to create a recommender are beyond the scope of this documentation,
+Instructions for how to create a recommender are beyond the scope of this documentation.
 ====
 
 .Procedure

modules/nodes-pods-vertical-autoscaler-moving-vpa.adoc

@@ -340,7 +340,7 @@ endif::vpa[]
 $ oc get pods -n openshift-vertical-pod-autoscaler -o wide
 ----
 +
-The pods are no longer deployed to the control plane nodes.
+The pods are no longer deployed to the control plane nodes. In the example output below, the node is now an infra node, not a control plane node.
 +
 .Example output
 [source,terminal]

modules/nodes-pods-vertical-autoscaler-tuning.adoc

@@ -8,13 +8,13 @@
 
 As a cluster administrator, you can tune the performance of your Vertical Pod Autoscaler Operator (VPA) to limit the rate at which the VPA makes requests of the Kubernetes API server and to specify the CPU and memory resources for the VPA recommender, updater, and admission controller component pods.
 
-Additionally, you can configure the VPA Operator to monitor only those workloads that are being managed by a VPA custom resource (CR). By default, the VPA Operator monitors every workload in the cluster. This allows the VPA Operator to accrue and store 8 days of historical data for all workloads, which the Operator can use if a new VPA CR is created for a workload. However, this causes the VPA Operator to use significant CPU and memory, which could cause the Operator to fail, particularly on larger clusters. By configuring the VPA Operator to monitor only workloads with a VPA CR, you can save on CPU and memory resources. One trade-off is that if you have a workload that has been running, and you create a VPA CR to manage that workload, the VPA Operator does not have any historical data for that workload. As a result, the initial recommendations are not as useful as those after the workload had been running for some time.
+Additionally, you can configure the VPA Operator to monitor only those workloads that are being managed by a VPA custom resource (CR). By default, the VPA Operator monitors every workload in the cluster. This allows the VPA Operator to accrue and store 8 days of historical data for all workloads, which the Operator can use if a new VPA CR is created for a workload. However, this causes the VPA Operator to use significant CPU and memory, which could cause the Operator to fail, particularly on larger clusters. By configuring the VPA Operator to monitor only workloads with a VPA CR, you can save on CPU and memory resources. One trade-off is that if you have a workload that has been running, and you create a VPA CR to manage that workload, the VPA Operator does not have any historical data for that workload. As a result, the initial recommendations are not as useful as those after the workload has been running for some time.
 
 These tunings allow you to ensure the VPA has sufficient resources to operate at peak efficiency and to prevent throttling and a possible delay in pod admissions. 
 
 You can perform the following tunings on the VPA components by editing the `VerticalPodAutoscalerController` custom resource (CR):
 
-* To prevent throttling and pod admission delays, set the queries-per-second (QPS) and burst rates for VPA requests of the Kubernetes API server by using the `kube-api-qps` and `kube-api-burst` parameters.
+* To prevent throttling and pod admission delays, set the queries per second (QPS) and burst rates for VPA requests of the Kubernetes API server by using the `kube-api-qps` and `kube-api-burst` parameters.
 
 * To ensure sufficient CPU and memory, set the CPU and memory requests for VPA component pods by using the standard `cpu` and `memory` resource requests.
 

modules/nodes-pods-vertical-autoscaler-using-about.adoc

@@ -267,7 +267,7 @@ spec:
 <1> The type of workload object you want this VPA CR to manage.
 <2> The name of the workload object you want this VPA CR to manage.
 <3> Set the mode to `Auto`, `Recreate`, `Initial`, or `Off`. The `Recreate` mode should be used rarely, only if you need to ensure that the pods are restarted whenever the resource request changes.
-<4> Specify the containers you want to opt-out and set `mode` to `Off`.
+<4> Specify the containers that you do not want updated by the VPA and set the `mode` to `Off`.
 
 For example, a pod has two containers, the same resource requests and limits: