Fix minor documentation issues based on drift and feedback (#5011)

This commit re-adds some documentation changes from late last year that
were lost during some major refactoring. It also addresses some feedback
submitted through the form that was missed during the interim period
since as a result of some automation disconnecting, which meant the
primary place the feedback is viewed received no updates.

README.md

@@ -63,7 +63,7 @@ The Ingress resource supports the following features:
   requests with the URI that starts with `/serviceB` to service B.
 - **TLS/SSL termination** for each hostname, such as `foo.example.com`.
 
-See the [Ingress User Guide](https://kubernetes.io/docs/user-guide/ingress/) to learn more about the Ingress resource.
+See the [Ingress User Guide](https://kubernetes.io/docs/concepts/services-networking/ingress/) to learn more about the Ingress resource.
 
 ### What is the Ingress Controller?
 

docs/content/configuration/global-configuration/command-line-arguments.md

@@ -173,7 +173,7 @@ Sets the URI of health status location in the default server. Requires [-health-
 ### -ingress-class `<string>`
 
 The `-ingress-class` argument refers to the name of the resource `kind: IngressClass`. An IngressClass resource with a name equal to the class must be deployed. Otherwise, NGINX Ingress Controller will fail to start.
-NGINX Ingress Controller will process Ingress resources that belong to its class, that is, those that have the `ingressClassName` field equal to the value of `-ingress-class` and skip the ones without it. It will also process all the VirtualServer/VirtualServerRoute/TransportServer resources that do not have the `ingressClassName` field.
+NGINX Ingress Controller will only process Ingress resources that belong to its class (Whose `ingressClassName` value matches the value of `-ingress-class`), skipping the ones without it. It will also process all the VirtualServer/VirtualServerRoute/TransportServer resources that do not have the `ingressClassName` field.
 
 Default `nginx`.
 

docs/content/configuration/security.md

@@ -60,7 +60,7 @@ When using manifests instead of Helm, uncomment the following sections of the de
 
 - `readOnlyRootFilesystem: true`,
 - The entire `volumeMounts` section,
-- The entire `initContiners` section,
+- The entire `initContainers` section,
 - For `initContainers:image:`, use exact same image used for regular NIC installation.
 Refer to the below code-block for guidance:
 

docs/content/installation/installing-nic/installation-with-operator.md

@@ -52,7 +52,8 @@ spec:
       pullPolicy: IfNotPresent
       repository: nginx/nginx-ingress
       tag: 3.4.2-ubi
-    ingressClass: nginx
+    ingressClass:
+      name: nginx
     kind: deployment
     nginxplus: false
     replicaCount: 1

docs/content/installation/running-multiple-ingress-controllers.md

@@ -45,9 +45,9 @@ When running NGINX Ingress Controller, you have the following options with regar
 
 - Cluster-wide Ingress Controller (default): NGINX Ingress Controller handles configuration resources created in any namespace of the cluster. As NGINX is a high-performance load balancer capable of serving many applications at the same time, this option is used by default in our installation manifests and Helm chart.
 - Defined-namespace Ingress Controller: You can configure the Ingress Controller to handle configuration resources only from particular namespaces, which is controlled through the `-watch-namespace` command-line argument. This can be useful if you want to use different NGINX Ingress Controllers for different applications, both in terms of isolation and/or operation.
-- Ingress Controller for Specific Ingress Class: This option works in conjunction with either of the options above. You can further customize which configuration resources are handled by the Ingress Controller by configuring the class of the Ingress Controller and using that class in your configuration resources. See the section [Configuring Ingress Class](#configuring-ingress-class).
+- Ingress Controller for Specific Ingress Class: This option works in conjunction with either of the options above. You can further customize which configuration resources are handled by the Ingress Controller by configuring the class of the Ingress Controller and using that class in your configuration resources. The [Configuring Ingress Class](#configuring-ingress-class) section above explains where.
 
-Using the options above you can run multiple NGINX Ingress Controllers, each handling a different set of configuration resources.
+These options allow you to run multiple NGINX Ingress Controllers, each handling a different set of configuration resources.
 
 {{< see-also >}}[Command-line arguments]({{< relref "configuration/global-configuration/command-line-arguments" >}}){{< /see-also >}}