Optimize the document for readability (kubernetes#9551)

Signed-off-by: Fish-pro <[email protected]>

docs/how-it-works.md

@@ -10,7 +10,7 @@ The goal of this Ingress controller is the assembly of a configuration file (ngi
 
 Usually, a Kubernetes Controller utilizes the [synchronization loop pattern][1] to check if the desired state in the controller is updated or a change is required. To this purpose, we need to build a model using different objects from the cluster, in particular (in no special order) Ingresses, Services, Endpoints, Secrets, and Configmaps to generate a point in time configuration file that reflects the state of the cluster.
 
-To get this object from the cluster, we use [Kubernetes Informers][2], in particular, `FilteredSharedInformer`. This informers allows reacting to changes in using [callbacks][3] to individual changes when a new object is added, modified or removed. Unfortunately, there is no way to know if a particular change is going to affect the final configuration file. Therefore on every change, we have to rebuild a new model from scratch based on the state of cluster and compare it to the current model. If the new model equals to the current one, then we avoid generating a new NGINX configuration and triggering a reload. Otherwise, we check if the difference is only about Endpoints. If so we then send the new list of Endpoints to a Lua handler running inside Nginx using HTTP POST request and again avoid generating a new NGINX configuration and triggering a reload. If the difference between running and new model is about more than just Endpoints we create a new NGINX configuration based on the new model, replace the current model and trigger a reload.
+To get this object from the cluster, we use [Kubernetes Informers][2], in particular, `FilteredSharedInformer`. These informers allow reacting to change in using [callbacks][3] to individual changes when a new object is added, modified or removed. Unfortunately, there is no way to know if a particular change is going to affect the final configuration file. Therefore on every change, we have to rebuild a new model from scratch based on the state of cluster and compare it to the current model. If the new model equals to the current one, then we avoid generating a new NGINX configuration and triggering a reload. Otherwise, we check if the difference is only about Endpoints. If so we then send the new list of Endpoints to a Lua handler running inside Nginx using HTTP POST request and again avoid generating a new NGINX configuration and triggering a reload. If the difference between running and new model is about more than just Endpoints we create a new NGINX configuration based on the new model, replace the current model and trigger a reload.
 
 One of the uses of the model is to avoid unnecessary reloads when there's no change in the state and to detect conflicts in definitions.
 

docs/user-guide/k8s-122-migration.md

@@ -131,7 +131,7 @@ and add the value `spec.ingressClassName=nginx` in your Ingress objects.
 
 ## I have many ingress objects in my cluster. What should I do?
 
-If you have lot of ingress objects without ingressClass configuration,
+If you have a lot of ingress objects without ingressClass configuration,
 you can run the ingress controller with the flag `--watch-ingress-without-class=true`.
 
 ### What is the flag `--watch-ingress-without-class`?
@@ -187,10 +187,10 @@ Bear in mind that if you start Ingress-Nginx B with the command line argument `-
 4. If you start Ingress-Nginx B with the command line argument `--watch-ingress-without-class=true` and you run Ingress-Nginx A with the command line argument `--watch-ingress-without-class=false` then this is a supported configuration.
    If you have two ingress-nginx controllers for the same cluster, both running with `--watch-ingress-without-class=true` then there is likely to be a conflict.
 
-## Why am I am seeing "ingress class annotation is not equal to the expected by Ingress Controller" in my controller logs?
+## Why am I seeing "ingress class annotation is not equal to the expected by Ingress Controller" in my controller logs?
 
 It is highly likely that you will also see the name of the ingress resource in the same error message.
-This error message has been observed on use the deprecated annotation (`kubernetes.io/ingress.class`) in a Ingress resource manifest.
+This error message has been observed on use the deprecated annotation (`kubernetes.io/ingress.class`) in an Ingress resource manifest.
 It is recommended to use the `.spec.ingressClassName` field of the Ingress resource, to specify the name of the IngressClass of the Ingress you are defining.
 
 ## How can I easily install multiple instances of the ingress-nginx controller in the same cluster?

docs/user-guide/miscellaneous.md

@@ -27,7 +27,7 @@ Support for websockets is provided by NGINX out of the box. No special configura
 
 The only requirement to avoid the close of connections is the increase of the values of `proxy-read-timeout` and `proxy-send-timeout`.
 
-The default value of this settings is `60 seconds`.
+The default value of these settings is `60 seconds`.
 
 A more adequate value to support websockets is a value higher than one hour (`3600`).
 

docs/user-guide/monitoring.md

@@ -170,16 +170,16 @@ According to the above example, this URL will be http://10.192.0.3:31086
   - By default request metrics are labeled with the hostname. When you have a wildcard domain ingress, then there will be no metrics for that ingress (to prevent the metrics from exploding in cardinality). To get metrics in this case you need to run the ingress controller with `--metrics-per-host=false` (you will lose labeling by hostname, but still have labeling by ingress).
 
 ### Grafana dashboard using ingress resource
-  - If you want to expose the dashboard for grafana using a ingress resource, then you can :
+  - If you want to expose the dashboard for grafana using an ingress resource, then you can :
     - change the service type of the prometheus-server service and the grafana service to "ClusterIP" like this :
     ```
     kubectl -n ingress-nginx edit svc grafana
     ```
     - This will open the currently deployed service grafana in the default editor configured in your shell (vi/nvim/nano/other)
     - scroll down to line 34 that looks like "type: NodePort"
     - change it to look like "type: ClusterIP". Save and exit.
-    - create a ingress resource with backend as "grafana" and port as "3000"
-  - Similarly, you can edit the service "prometheus-server" and add a ingress resource.
+    - create an ingress resource with backend as "grafana" and port as "3000"
+  - Similarly, you can edit the service "prometheus-server" and add an ingress resource.
 
 ## Prometheus and Grafana installation using Service Monitors
 This document assumes you're using helm and using the kube-prometheus-stack package to install Prometheus and Grafana.

docs/user-guide/multiple-ingress.md

@@ -2,7 +2,7 @@
 
 By default, deploying multiple Ingress controllers (e.g., `ingress-nginx` & `gce`) will result in all controllers simultaneously racing to update Ingress status fields in confusing ways.
 
-To fix this problem, use [IngressClasses](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class). The `kubernetes.io/ingress.class` annotation is not being preferred or suggested to use as it can be deprecated in future. Better to use the field `ingress.spec.ingressClassName`.
+To fix this problem, use [IngressClasses](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class). The `kubernetes.io/ingress.class` annotation is not being preferred or suggested to use as it can be deprecated in the future. Better to use the field `ingress.spec.ingressClassName`.
 But, when user has deployed with `scope.enabled`, then the ingress class resource field is not used.