Fix names in documentation (#7940)

* Fix names in documentation

This fixes the documentation to reflect the name change from
`nginx-ingress` to `ingress-nginx`.

Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>

* Revert accidental changelog update

Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>

docs/deploy/index.md

@@ -288,7 +288,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/cont
 
 ### Checking ingress controller version
 
-Run `nginx-ingress-controller --version` within the pod, for instance with `kubectl exec`:
+Run `ingress-nginx-controller --version` within the pod, for instance with `kubectl exec`:
 
 ```console
 POD_NAMESPACE=ingress-nginx

docs/deploy/rbac.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-This example applies to nginx-ingress-controllers being deployed in an environment with RBAC enabled.
+This example applies to ingress-nginx-controllers being deployed in an environment with RBAC enabled.
 
 Role Based Access Control is comprised of four layers:
 
@@ -11,25 +11,25 @@ Role Based Access Control is comprised of four layers:
 3. `Role` - permissions assigned to a role that apply to a specific namespace
 4. `RoleBinding` - binding a Role to a specific account
 
-In order for RBAC to be applied to an nginx-ingress-controller, that controller
+In order for RBAC to be applied to an ingress-nginx-controller, that controller
 should be assigned to a `ServiceAccount`.  That `ServiceAccount` should be
-bound to the `Role`s and `ClusterRole`s defined for the nginx-ingress-controller.
+bound to the `Role`s and `ClusterRole`s defined for the ingress-nginx-controller.
 
 ## Service Accounts created in this example
 
-One ServiceAccount is created in this example, `nginx-ingress-serviceaccount`.
+One ServiceAccount is created in this example, `ingress-nginx`.
 
 ## Permissions Granted in this example
 
 There are two sets of permissions defined in this example.  Cluster-wide
-permissions defined by the `ClusterRole` named `nginx-ingress-clusterrole`, and
-namespace specific permissions defined by the `Role` named `nginx-ingress-role`.
+permissions defined by the `ClusterRole` named `ingress-nginx`, and
+namespace specific permissions defined by the `Role` named `ingress-nginx`.
 
 ### Cluster Permissions
 
-These permissions are granted in order for the nginx-ingress-controller to be
+These permissions are granted in order for the ingress-nginx-controller to be
 able to function as an ingress across the cluster.  These permissions are
-granted to the ClusterRole named `nginx-ingress-clusterrole`
+granted to the ClusterRole named `ingress-nginx`
 
 * `configmaps`, `endpoints`, `nodes`, `pods`, `secrets`: list, watch
 * `nodes`: get
@@ -39,13 +39,13 @@ granted to the ClusterRole named `nginx-ingress-clusterrole`
 
 ### Namespace Permissions
 
-These permissions are granted specific to the nginx-ingress namespace.  These
-permissions are granted to the Role named `nginx-ingress-role`
+These permissions are granted specific to the ingress-nginx namespace.  These
+permissions are granted to the Role named `ingress-nginx`
 
 * `configmaps`, `pods`, `secrets`: get
 * `endpoints`: get
 
-Furthermore to support leader-election, the nginx-ingress-controller needs to
+Furthermore to support leader-election, the ingress-nginx-controller needs to
 have access to a `configmap` using the resourceName `ingress-controller-leader-nginx`
 
 > Note that resourceNames can NOT be used to limit requests using the “create”
@@ -64,13 +64,13 @@ This resourceName is the concatenation of the `election-id` and the
 * `resourceName` : `<election-id>-<ingress-class>`
 
 Please adapt accordingly if you overwrite either parameter when launching the
-nginx-ingress-controller.
+ingress-nginx-controller.
 
 ### Bindings
 
-The ServiceAccount `nginx-ingress-serviceaccount` is bound to the Role
-`nginx-ingress-role` and the ClusterRole `nginx-ingress-clusterrole`.
+The ServiceAccount `ingress-nginx` is bound to the Role
+`ingress-nginx` and the ClusterRole `ingress-nginx`.
 
 The serviceAccountName associated with the containers in the deployment must
 match the serviceAccount. The namespace references in the Deployment metadata, 
-container arguments, and POD_NAMESPACE should be in the nginx-ingress namespace.
+container arguments, and POD_NAMESPACE should be in the ingress-nginx namespace.

docs/deploy/upgrade.md

@@ -14,7 +14,7 @@ I.e. if your deployment resource looks like (partial example):
 ```yaml
 kind: Deployment
 metadata:
-  name: nginx-ingress-controller
+  name: ingress-nginx-controller
   namespace: ingress-nginx
 spec:
   replicas: 1
@@ -23,21 +23,21 @@ spec:
     metadata: ...
     spec:
       containers:
-        - name: nginx-ingress-controller
-          image: k8s.gcr.io/ingress-nginx/controller:v0.34.0@sha256:56633bd00dab33d92ba14c6e709126a762d54a75a6e72437adefeaaca0abb069
+        - name: ingress-nginx-controller
+          image: k8s.gcr.io/ingress-nginx/controller:v1.0.4@sha256:545cff00370f28363dad31e3b59a94ba377854d3a11f18988f5f9e56841ef9ef
           args: ...
 ```
 
-simply change the `0.34.0` tag to the version you wish to upgrade to.
+simply change the `v1.0.4` tag to the version you wish to upgrade to.
 The easiest way to do this is e.g. (do note you may need to change the name parameter according to your installation):
 
 ```
-kubectl set image deployment/nginx-ingress-controller \
-  nginx-ingress-controller=k8s.gcr.io/ingress-nginx/controller:v0.34.1@sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20 \
+kubectl set image deployment/ingress-nginx-controller \
+  controller=k8s.gcr.io/ingress-nginx/controller:v1.0.5@sha256:55a1fcda5b7657c372515fe402c3e39ad93aa59f6e4378e82acd99912fe6028d \
   -n ingress-nginx
 ```
 
-For interactive editing, use `kubectl edit deployment nginx-ingress-controller -n ingress-nginx`.
+For interactive editing, use `kubectl edit deployment ingress-nginx-controller -n ingress-nginx`.
 
 ## With Helm