Keep project name display aligned (#9920)

deploy/grafana/dashboards/README.md

@@ -4,7 +4,7 @@ Ingress-nginx supports a rich collection of prometheus metrics.  If you have pro
 
 This folder contains two dashboards that you can import.
 
-## 1. NGINX Ingress Controller
+## 1. Ingress-Nginx Controller
 
 ![Dashboard](screenshot.png)
 

docs/deploy/baremetal.md

@@ -1,14 +1,14 @@
 # Bare-metal considerations
 
 In traditional *cloud* environments, where network load balancers are available on-demand, a single Kubernetes manifest
-suffices to provide a single point of contact to the NGINX Ingress controller to external clients and, indirectly, to
+suffices to provide a single point of contact to the Ingress-Nginx Controller to external clients and, indirectly, to
 any application running inside the cluster. *Bare-metal* environments lack this commodity, requiring a slightly
 different setup to offer the same kind of access to external consumers.
 
 ![Cloud environment](../images/baremetal/cloud_overview.jpg)
 ![Bare-metal environment](../images/baremetal/baremetal_overview.jpg)
 
-The rest of this document describes a few recommended approaches to deploying the NGINX Ingress controller inside a
+The rest of this document describes a few recommended approaches to deploying the Ingress-Nginx Controller inside a
 Kubernetes cluster running on bare-metal.
 
 ## A pure software solution: MetalLB
@@ -30,7 +30,7 @@ the traffic for the `ingress-nginx` Service IP. See [Traffic policies][metallb-t
     yourself by reading the official documentation thoroughly.
 
 MetalLB can be deployed either with a simple Kubernetes manifest or with Helm. The rest of this example assumes MetalLB
-was deployed following the [Installation][metallb-install] instructions, and that the NGINX Ingress controller was installed 
+was deployed following the [Installation][metallb-install] instructions, and that the Ingress-Nginx Controller was installed 
 using the steps described in the [quickstart section of the installation guide][install-quickstart].
 
 MetalLB requires a pool of IP addresses in order to be able to take ownership of the `ingress-nginx` Service. This pool
@@ -164,7 +164,7 @@ field of the `ingress-nginx` Service spec to `Local` ([example][preserve-ip]).
 !!! warning
     This setting effectively **drops packets** sent to Kubernetes nodes which are not running any instance of the NGINX
     Ingress controller. Consider [assigning NGINX Pods to specific nodes][pod-assign] in order to control on what nodes
-    the NGINX Ingress controller should be scheduled or not scheduled.
+    the Ingress-Nginx Controller should be scheduled or not scheduled.
 
 !!! example
     In a Kubernetes cluster composed of 3 nodes (the external IP is added as an example, in most bare-metal environments
@@ -193,7 +193,7 @@ field of the `ingress-nginx` Service spec to `Local` ([example][preserve-ip]).
 
 * **Ingress status**
 
-Because NodePort Services do not get a LoadBalancerIP assigned by definition, the NGINX Ingress controller **does not
+Because NodePort Services do not get a LoadBalancerIP assigned by definition, the Ingress-Nginx Controller **does not
 update the status of Ingress objects it manages**.
 
 ```console
@@ -202,12 +202,12 @@ NAME           HOSTS               ADDRESS   PORTS
 test-ingress   myapp.example.com             80
 ```
 
-Despite the fact there is no load balancer providing a public IP address to the NGINX Ingress controller, it is possible
+Despite the fact there is no load balancer providing a public IP address to the Ingress-Nginx Controller, it is possible
 to force the status update of all managed Ingress objects by setting the `externalIPs` field of the `ingress-nginx`
 Service.
 
 !!! warning
-    There is more to setting `externalIPs` than just enabling the NGINX Ingress controller to update the status of
+    There is more to setting `externalIPs` than just enabling the Ingress-Nginx Controller to update the status of
     Ingress objects. Please read about this option in the [Services][external-ips] page of official Kubernetes
     documentation as well as the section about [External IPs](#external-ips) in this document for more information.
 
@@ -268,11 +268,11 @@ for generating redirect URLs that take into account the URL used by external cli
 
 In a setup where there is no external load balancer available but using NodePorts is not an option, one can configure
 `ingress-nginx` Pods to use the network of the host they run on instead of a dedicated network namespace. The benefit of
-this approach is that the NGINX Ingress controller can bind ports 80 and 443 directly to Kubernetes nodes' network
+this approach is that the Ingress-Nginx Controller can bind ports 80 and 443 directly to Kubernetes nodes' network
 interfaces, without the extra network translation imposed by NodePort Services.
 
 !!! note
-    This approach does not leverage any Service object to expose the NGINX Ingress controller. If the `ingress-nginx`
+    This approach does not leverage any Service object to expose the Ingress-Nginx Controller. If the `ingress-nginx`
     Service exists in the target cluster, it is **recommended to delete it**.
 
 This can be achieved by enabling the `hostNetwork` option in the Pods' spec.
@@ -284,7 +284,7 @@ template:
 ```
 
 !!! danger "Security considerations"
-    Enabling this option **exposes every system daemon to the NGINX Ingress controller** on any network interface,
+    Enabling this option **exposes every system daemon to the Ingress-Nginx Controller** on any network interface,
     including the host's loopback. Please evaluate the impact this may have on the security of your system carefully.
 
 !!! example
@@ -299,7 +299,7 @@ template:
     ingress-nginx-controller-5b4cf5fc6-lzrls   1/1     Running   203.0.113.2   host-2
     ```
 
-One major limitation of this deployment approach is that only **a single NGINX Ingress controller Pod** may be scheduled
+One major limitation of this deployment approach is that only **a single Ingress-Nginx Controller Pod** may be scheduled
 on each cluster node, because binding the same port multiple times on the same network interface is technically
 impossible. Pods that are unschedulable due to such situation fail with the following event:
 
@@ -312,7 +312,7 @@ Events:
   Warning  FailedScheduling  default-scheduler  0/3 nodes are available: 3 node(s) didn't have free ports for the requested pod ports.
 ```
 
-One way to ensure only schedulable Pods are created is to deploy the NGINX Ingress controller as a *DaemonSet* instead
+One way to ensure only schedulable Pods are created is to deploy the Ingress-Nginx Controller as a *DaemonSet* instead
 of a traditional Deployment.
 
 !!! info
@@ -334,7 +334,7 @@ expected to resolve internal names for any reason.
 
 * **Ingress status**
 
-Because there is no Service exposing the NGINX Ingress controller in a configuration using the host network, the default
+Because there is no Service exposing the Ingress-Nginx Controller in a configuration using the host network, the default
 `--publish-service` flag used in standard cloud setups **does not apply** and the status of all Ingress objects remains
 blank.
 
@@ -346,7 +346,7 @@ test-ingress   myapp.example.com             80
 
 Instead, and because bare-metal nodes usually don't have an ExternalIP, one has to enable the
 [`--report-node-internal-ip-address`][cli-args] flag, which sets the status of all Ingress objects to the internal IP
-address of all nodes running the NGINX Ingress controller.
+address of all nodes running the Ingress-Nginx Controller.
 
 !!! example
     Given a `ingress-nginx-controller` DaemonSet composed of 2 replicas

docs/deploy/hardening-guide.md

@@ -94,7 +94,7 @@ This guide refers to chapters in the CIS Benchmark. For full explanation you sho
 | __5 Request Filtering and Restrictions__||| |
 | ||| |
 | __5.1 Access Control__||| |
-| 5.1.1 Ensure allow and deny filters limit access to specific IP addresses (Not Scored)| OK/ACTION NEEDED | Depends on use case, geo ip module is compiled into nginx ingress controller, there are several ways to use it | If needed set IP restrictions via annotations or work with config snippets (be careful with lets-encrypt-http-challenge!) |
+| 5.1.1 Ensure allow and deny filters limit access to specific IP addresses (Not Scored)| OK/ACTION NEEDED | Depends on use case, geo ip module is compiled into Ingress-Nginx Controller, there are several ways to use it | If needed set IP restrictions via annotations or work with config snippets (be careful with lets-encrypt-http-challenge!) |
 | 5.1.2 Ensure only whitelisted HTTP methods are allowed (Not Scored) | OK/ACTION NEEDED | Depends on use case| If required it can be set via config snippet|
 | ||| |
 | __5.2 Request Limits__||| |

docs/deploy/index.md

@@ -1,6 +1,6 @@
 # Installation Guide
 
-There are multiple ways to install the NGINX ingress controller:
+There are multiple ways to install the Ingress-Nginx Controller:
 
 - with [Helm](https://helm.sh), using the project repository chart;
 - with `kubectl apply`, using YAML manifests;
@@ -192,9 +192,9 @@ doesn't work, you might have to fall back to the `kubectl port-forward` method d
 
 Rancher Desktop provides Kubernetes and Container Management on the desktop. Kubernetes is enabled by default in Rancher Desktop. 
 
-Rancher Desktop uses K3s under the hood, which in turn uses Traefik as the default ingress controller for the Kubernetes cluster. To use NGINX ingress controller in place of the default Traefik, disable Traefik from Preference > Kubernetes menu.
+Rancher Desktop uses K3s under the hood, which in turn uses Traefik as the default ingress controller for the Kubernetes cluster. To use Ingress-Nginx Controller in place of the default Traefik, disable Traefik from Preference > Kubernetes menu.
 
-Once traefik is disabled, the NGINX ingress controller can be installed on Rancher Desktop using the default [quick start](#quick-start) instructions. Follow the instructions described in the [local testing section](#local-testing) to try a sample.
+Once traefik is disabled, the Ingress-Nginx Controller can be installed on Rancher Desktop using the default [quick start](#quick-start) instructions. Follow the instructions described in the [local testing section](#local-testing) to try a sample.
 
 ### Cloud deployments
 
@@ -214,7 +214,7 @@ options of various cloud providers.
 
 #### AWS
 
-In AWS, we use a Network load balancer (NLB) to expose the NGINX Ingress controller behind a Service of `Type=LoadBalancer`.
+In AWS, we use a Network load balancer (NLB) to expose the Ingress-Nginx Controller behind a Service of `Type=LoadBalancer`.
 
 !!! info
     The provided templates illustrate the setup for legacy in-tree service load balancer for AWS NLB.
@@ -419,14 +419,14 @@ Here is how these Ingress versions are supported in Kubernetes:
 - from Kubernetes 1.19 to 1.21, both `v1beta1` and `v1` Ingress resources are supported
 - in Kubernetes 1.22 and above, only `v1` Ingress resources are supported
 
-And here is how these Ingress versions are supported in NGINX Ingress Controller:
+And here is how these Ingress versions are supported in Ingress-Nginx Controller:
 - before version 1.0, only `v1beta1` Ingress resources are supported
 - in version 1.0 and above, only `v1` Ingress resources are
 
 As a result, if you're running Kubernetes 1.19 or later, you should be able to use the latest version of the NGINX 
 Ingress Controller; but if you're using an old version of Kubernetes (1.18 or earlier) you will have to use version 0.X 
-of the NGINX Ingress Controller (e.g. version 0.49).
+of the Ingress-Nginx Controller (e.g. version 0.49).
 
-The Helm chart of the NGINX Ingress Controller switched to version 1 in version 4 of the chart. In other words, if 
+The Helm chart of the Ingress-Nginx Controller switched to version 1 in version 4 of the chart. In other words, if 
 you're running Kubernetes 1.19 or earlier, you should use version 3.X of the chart (this can be done by adding 
 `--version='<4'` to the `helm install` command ).

docs/developer-guide/code-overview.md

@@ -53,7 +53,7 @@ This code can be found in [internal/file](https://github.com/kubernetes/ingress-
 
 #### Ingress functions
 
-Contains all the logics from NGINX Ingress Controller, with some examples being:
+Contains all the logics from Ingress-Nginx Controller, with some examples being:
 
 * Expected Golang structures that will be used in templates and other parts of the code - [internal/ingress/types.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/types.go).
 * supported annotations and its parsing logics - [internal/ingress/annotations](https://github.com/kubernetes/ingress-nginx/tree/main/internal/ingress/annotations).

docs/developer-guide/getting-started.md

@@ -1,6 +1,6 @@
- Developing for NGINX Ingress Controller
+ Developing for Ingress-Nginx Controller
 
-This document explains how to get started with developing for NGINX Ingress controller.
+This document explains how to get started with developing for Ingress-Nginx Controller.
 
 For the really new contributors, who want to contribute to the INGRESS-NGINX project, but need help with understanding some basic concepts,
 that are needed to work with the Kubernetes ingress resource, here is a link to the [New Contributors Guide](https://github.com/kubernetes/ingress-nginx/blob/main/NEW_CONTRIBUTOR.md).

docs/examples/affinity/cookie/README.md

@@ -67,7 +67,7 @@ Accept-Ranges: bytes
 ```
 
 In the example above, you can see that the response contains a `Set-Cookie` header with the settings we have defined.
-This cookie is created by the NGINX Ingress Controller, it contains a randomly generated key corresponding to the upstream used for that request (selected using [consistent hashing][consistent-hashing]) and has an `Expires` directive.
+This cookie is created by the Ingress-Nginx Controller, it contains a randomly generated key corresponding to the upstream used for that request (selected using [consistent hashing][consistent-hashing]) and has an `Expires` directive.
 If a client sends a cookie that doesn't correspond to an upstream, NGINX selects an upstream and creates a corresponding cookie.
 
 If the backend pool grows NGINX will keep sending the requests through the same server of the first request, even if it's overloaded.

docs/examples/customization/custom-errors/README.md

@@ -29,7 +29,7 @@ service/nginx-errors   ClusterIP   10.0.0.12   <none>        80/TCP    10s
 
 ## Ingress controller configuration
 
-If you do not already have an instance of the NGINX Ingress controller running, deploy it according to the
+If you do not already have an instance of the Ingress-Nginx Controller running, deploy it according to the
 [deployment guide][deploy], then follow these steps:
 
 1. Edit the `ingress-nginx-controller` Deployment and set the value of the `--default-backend-service` flag to the name of the
@@ -37,7 +37,7 @@ If you do not already have an instance of the NGINX Ingress controller running,
 
 2. Edit the `ingress-nginx-controller` ConfigMap and create the key `custom-http-errors` with a value of `404,503`.
 
-3. Take note of the IP address assigned to the NGINX Ingress controller Service.
+3. Take note of the IP address assigned to the Ingress-Nginx Controller Service.
     ```
     $ kubectl get svc ingress-nginx
     NAME            TYPE        CLUSTER-IP  EXTERNAL-IP   PORT(S)          AGE

docs/examples/customization/custom-headers/README.md

@@ -10,7 +10,7 @@ To work around this limitation, perform a rolling restart of the deployment.
 
 ## Example
 
-This example demonstrates configuration of the nginx ingress controller via
+This example demonstrates configuration of the Ingress-Nginx Controller via
 a ConfigMap to pass a custom list of headers to the upstream
 server.
 
@@ -26,7 +26,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/customization/custom-headers/configmap.yaml
 ```
 
-The nginx ingress controller will read the `ingress-nginx/ingress-nginx-controller` ConfigMap, find the `proxy-set-headers` key, read HTTP headers from the `ingress-nginx/custom-headers` ConfigMap, and include those HTTP headers in all requests flowing from nginx to the backends.
+The Ingress-Nginx Controller will read the `ingress-nginx/ingress-nginx-controller` ConfigMap, find the `proxy-set-headers` key, read HTTP headers from the `ingress-nginx/custom-headers` ConfigMap, and include those HTTP headers in all requests flowing from nginx to the backends.
 
 
 The above example was for passing a custom list of headers to the upstream server.

docs/examples/customization/ssl-dh-param/README.md

@@ -1,6 +1,6 @@
 # Custom DH parameters for perfect forward secrecy
 
-This example aims to demonstrate the deployment of an nginx ingress controller and
+This example aims to demonstrate the deployment of an Ingress-Nginx Controller and
 use a ConfigMap to configure a custom Diffie-Hellman parameters file to help with
 "Perfect Forward Secrecy".
 

docs/examples/tls-termination/README.md

@@ -1,6 +1,6 @@
 # TLS termination
 
-This example demonstrates how to terminate TLS through the nginx Ingress controller.
+This example demonstrates how to terminate TLS through the Ingress-Nginx Controller.
 
 ## Prerequisites
 

docs/how-it-works.md

@@ -60,7 +60,7 @@ In a relatively big cluster with frequently deploying apps this feature saves si
 
 Because the ingress controller works using the [synchronization loop pattern](https://coreos.com/kubernetes/docs/latest/replication-controller.html#the-reconciliation-loop-in-detail), it is applying the configuration for all matching objects. In case some Ingress objects have a broken configuration, for example a syntax error in the `nginx.ingress.kubernetes.io/configuration-snippet` annotation, the generated configuration becomes invalid, does not reload and hence no more ingresses will be taken into account.
 
-To prevent this situation to happen, the nginx ingress controller optionally exposes a [validating admission webhook server][8] to ensure the validity of incoming ingress objects.
+To prevent this situation to happen, the Ingress-Nginx Controller optionally exposes a [validating admission webhook server][8] to ensure the validity of incoming ingress objects.
 This webhook appends the incoming ingress objects to the list of ingresses, generates the configuration and calls nginx to ensure the configuration has no syntax errors.
 
 [0]: https://github.com/openresty/lua-nginx-module/pull/1259

docs/user-guide/cli-arguments.md

@@ -68,7 +68,7 @@ They are set in the container spec of the `ingress-nginx-controller` Deployment
 | `--validating-webhook`             | The address to start an admission controller on to validate incoming ingresses. Takes the form "<host>:port". If not provided, no admission controller is started. |
 | `--validating-webhook-certificate` | The path of the validating webhook certificate PEM. |
 | `--validating-webhook-key`         | The path of the validating webhook key PEM. |
-| `--version`                        | Show release information about the NGINX Ingress controller and exit. |
+| `--version`                        | Show release information about the Ingress-Nginx Controller and exit. |
 | `--watch-ingress-without-class`                        | Define if Ingress Controller should also watch for Ingresses without an IngressClass or the annotation specified. (default false) |
 | `--watch-namespace`                | Namespace the controller watches for updates to Kubernetes objects. This includes Ingresses, Services and all configuration resources. All namespaces are watched if this parameter is left empty. |
 | `--watch-namespace-selector`       | The controller will watch namespaces whose labels match the given selector. This flag only takes effective when `--watch-namespace` is empty. |

docs/user-guide/external-articles.md

@@ -2,5 +2,5 @@
 
 - [Pain(less) NGINX Ingress](http://danielfm.me/posts/painless-nginx-ingress.html)
 - [Accessing Kubernetes Pods from Outside of the Cluster](http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster)
-- [Kubernetes - Redirect HTTP to HTTPS with ELB and the nginx ingress controller](https://dev.to/tomhoule/kubernetes---redirect-http-to-https-with-elb-and-the-nginx-ingress-controller)
+- [Kubernetes - Redirect HTTP to HTTPS with ELB and the Ingress-Nginx Controller](https://dev.to/tomhoule/kubernetes---redirect-http-to-https-with-elb-and-the-nginx-ingress-controller)
 - [Configure Nginx Ingress Controller for TLS termination on Kubernetes on Azure](https://blogs.technet.microsoft.com/livedevopsinjapan/2017/02/28/configure-nginx-ingress-controller-for-tls-termination-on-kubernetes-on-azure-2/)

docs/user-guide/miscellaneous.md

@@ -32,7 +32,7 @@ The default value of these settings is `60 seconds`.
 A more adequate value to support websockets is a value higher than one hour (`3600`).
 
 !!! Important
-    If the NGINX ingress controller is exposed with a service `type=LoadBalancer` make sure the protocol between the loadbalancer and NGINX is TCP.
+    If the Ingress-Nginx Controller is exposed with a service `type=LoadBalancer` make sure the protocol between the loadbalancer and NGINX is TCP.
 
 ## Optimizing TLS Time To First Byte (TTTFB)
 
@@ -52,4 +52,4 @@ The previous behavior can be restored using `retry-non-idempotent=true` in the c
 
 ## Why endpoints and not services
 
-The NGINX ingress controller does not use [Services](http://kubernetes.io/docs/user-guide/services) to route traffic to the pods. Instead it uses the Endpoints API in order to bypass [kube-proxy](http://kubernetes.io/docs/admin/kube-proxy/) to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT.
+The Ingress-Nginx Controller does not use [Services](http://kubernetes.io/docs/user-guide/services) to route traffic to the pods. Instead it uses the Endpoints API in order to bypass [kube-proxy](http://kubernetes.io/docs/admin/kube-proxy/) to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT.

docs/user-guide/monitoring.md

@@ -6,14 +6,14 @@ Two different methods to install and configure Prometheus and Grafana are descri
 
 ## Prometheus and Grafana installation using Pod Annotations
 
-This tutorial will show you how to install [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/) for scraping the metrics of the NGINX Ingress controller.
+This tutorial will show you how to install [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/) for scraping the metrics of the Ingress-Nginx Controller.
 
 !!! important
     This example uses `emptyDir` volumes for Prometheus and Grafana. This means once the pod gets terminated you will lose all the data.
 
 ### Before You Begin
 
-- The NGINX Ingress controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
+- The Ingress-Nginx Controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
 
 - The controller should be configured for exporting metrics. This requires 3 configurations to the controller. These configurations are :
   1. controller.metrics.enabled=true
@@ -184,9 +184,9 @@ According to the above example, this URL will be http://10.192.0.3:31086
 ## 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.
 
-### Verify NGINX Ingress controller is installed
+### Verify Ingress-Nginx Controller is installed
 
-- The NGINX Ingress controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
+- The Ingress-Nginx Controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
 
 - To check if Ingress controller is deployed,
   ```
@@ -214,7 +214,7 @@ This document assumes you're using helm and using the kube-prometheus-stack pack
 
 - If prometheus is not installed, then you can install from [here](https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack)
 
-### Re-configure NGINX Ingress controller
+### Re-configure Ingress-Nginx Controller
 
 - The Ingress NGINX controller needs to be reconfigured for exporting metrics. This requires 3 additional configurations to the controller. These configurations are :
   ```

docs/user-guide/multiple-ingress.md

@@ -111,7 +111,7 @@ spec:
 
 then setting the corresponding `kubernetes.io/ingress.class: "internal-nginx"` annotation on your Ingresses.
 
-To reiterate, setting the annotation to any value which does not match a valid ingress class will force the NGINX Ingress controller to ignore your Ingress.
+To reiterate, setting the annotation to any value which does not match a valid ingress class will force the Ingress-Nginx Controller to ignore your Ingress.
-If you are only running a single NGINX ingress controller, this can be achieved by setting the annotation to any value except "nginx" or an empty string.
+If you are only running a single Ingress-Nginx Controller, this can be achieved by setting the annotation to any value except "nginx" or an empty string.
 
 Do this if you wish to use one of the other Ingress controllers at the same time as the NGINX controller.

docs/user-guide/nginx-configuration/annotations.md

@@ -598,7 +598,7 @@ the User guide.
 
 ### Service Upstream
 
-By default the NGINX ingress controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration.
+By default the Ingress-Nginx Controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration.
 
 The `nginx.ingress.kubernetes.io/service-upstream` annotation disables that behavior and instead uses a single upstream in NGINX, the service's Cluster IP and port.
 

docs/user-guide/third-party-addons/opentelemetry.md

@@ -2,7 +2,7 @@
 
 Enables requests served by NGINX for distributed telemetry via The OpenTelemetry Project.
 
-Using the third party module [opentelemetry-cpp-contrib/nginx](https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/nginx) the NGINX ingress controller can configure NGINX to enable [OpenTelemetry](http://opentelemetry.io) instrumentation.
+Using the third party module [opentelemetry-cpp-contrib/nginx](https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/nginx) the Ingress-Nginx Controller can configure NGINX to enable [OpenTelemetry](http://opentelemetry.io) instrumentation.
 By default this feature is disabled.
 
 ## Usage

docs/user-guide/third-party-addons/opentracing.md

@@ -2,7 +2,7 @@
 
 Enables requests served by NGINX for distributed tracing via The OpenTracing Project.
 
-Using the third party module [opentracing-contrib/nginx-opentracing](https://github.com/opentracing-contrib/nginx-opentracing) the NGINX ingress controller can configure NGINX to enable [OpenTracing](http://opentracing.io) instrumentation.
+Using the third party module [opentracing-contrib/nginx-opentracing](https://github.com/opentracing-contrib/nginx-opentracing) the Ingress-Nginx Controller can configure NGINX to enable [OpenTracing](http://opentracing.io) instrumentation.
 By default this feature is disabled.
 
 ## Usage

images/README.md

@@ -13,7 +13,7 @@
 
 Directory | Purpose
 ------------ | -------------
-custom-error-pages | Example of Custom error pages for the NGINX Ingress controller
+custom-error-pages | Example of Custom error pages for the Ingress-Nginx Controller
 e2e | Image to run e2e tests
 fastcgi-helloserver | FastCGI application for e2e tests
 grpc-fortune-teller | grpc server application for the nginx-ingress grpc example

images/custom-error-pages/README.md

@@ -1,3 +1,3 @@
 # custom-error-pages
 
-Example of Custom error pages for the NGINX Ingress controller
+Example of Custom error pages for the Ingress-Nginx Controller

mkdocs.yml

@@ -1,4 +1,4 @@
-site_name: NGINX Ingress Controller
+site_name: Ingress-Nginx Controller
 repo_name: "kubernetes/ingress-nginx"
 repo_url: https://github.com/kubernetes/ingress-nginx
 site_url: https://kubernetes.github.io/ingress-nginx