Fix codeblock languages, prefix instances (#5604)

This commit replaces all instances of console with shell, ensuring that
codeblock highlighting and formatting is activated. It removes prefixes
from shell prompt (such as $), removes unnecessary blank lines and adds
languages to blocks that do not have them.

docs/content/configuration/global-configuration/globalconfiguration-resource.md

@@ -77,15 +77,15 @@ You can use the usual `kubectl` commands to work with a GlobalConfiguration reso
 
 For example, the following command creates a GlobalConfiguration resource defined in `global-configuration.yaml` with the name `nginx-configuration`:
 
-```
-$ kubectl apply -f global-configuration.yaml
+```shell
+kubectl apply -f global-configuration.yaml
 globalconfiguration.k8s.nginx.org/nginx-configuration created
 ```
 
 Assuming the namespace of the resource is `nginx-ingress`, you can get the resource by running:
 
-```
-$ kubectl get globalconfiguration nginx-configuration -n nginx-ingress
+```shell
+kubectl get globalconfiguration nginx-configuration -n nginx-ingress
 NAME                  AGE
 nginx-configuration   13s
 ```
@@ -128,8 +128,8 @@ The Ingress Controller validates the fields of a GlobalConfiguration resource. I
 
 You can check if the Ingress Controller successfully applied the configuration for a GlobalConfiguration. For our  `nginx-configuration` GlobalConfiguration, we can run:
 
-```
-$ kubectl describe gc nginx-configuration -n nginx-ingress
+```shell
+kubectl describe gc nginx-configuration -n nginx-ingress
 . . .
 Events:
   Type     Reason    Age   From                      Message
@@ -141,8 +141,8 @@ Note how the events section includes a Normal event with the Updated reason that
 
 If you create a GlobalConfiguration `nginx-configuration` with two or more listeners that have the same protocol UDP and port 53, you will get:
 
-```
-$ kubectl describe gc nginx-configuration -n nginx-ingress
+```shell
+kubectl describe gc nginx-configuration -n nginx-ingress
 . . .
 Events:
   Type     Reason    Age   From                      Message

docs/content/configuration/global-configuration/reporting-resources-status.md

@@ -34,16 +34,16 @@ Notes: NGINX Ingress Controller does not clear the status of Ingress resources w
 A VirtualServer or VirtualServerRoute resource includes the status field with information about the state of the resource and the IP address, through which the hosts of that resource are publicly accessible.
 You can see the status in the output of the `kubectl get virtualservers` or `kubectl get virtualserverroutes` commands as shown below:
 
-```
-$ kubectl get virtualservers
+```shell
+kubectl get virtualservers
   NAME   STATE   HOST                   IP            PORTS      AGE
   cafe   Valid   cafe.example.com       12.13.23.123  [80,443]   34s
 ```
 
 To see an external hostname address associated with a VirtualServer resource, use the `-o wide` option:
 
-```
-$ kubectl get virtualservers -o wide
+```shell
+kubectl get virtualservers -o wide
   NAME   STATE   HOST               IP    EXTERNALHOSTNAME                                                         PORTS      AGE
   cafe   Valid   cafe.example.com         ae430f41a1a0042908655abcdefghijkl-12345678.eu-west-2.elb.amazonaws.com   [80,443]   106s
 ```
@@ -52,8 +52,8 @@ $ kubectl get virtualservers -o wide
 
 In order to see additional addresses or extra information about the `Status` of the resource, use the following command:
 
-```
-$ kubectl describe virtualserver <NAME>
+```shell
+kubectl describe virtualserver <NAME>
 . . .
 Status:
   External Endpoints:
@@ -110,16 +110,16 @@ Notes: The Ingress Controller does not clear the status of VirtualServer and Vir
 A Policy resource includes the status field with information about the state of the resource.
 You can see the status in the output of the `kubectl get policy` command as shown below:
 
-```
-$ kubectl get policy
+```shell
+kubectl get policy
   NAME              STATE   AGE
   webapp-policy     Valid   30s
 ```
 
 In order to see additional addresses or extra information about the `Status` of the resource, use the following command:
 
-```
-$ kubectl describe policy <NAME>
+```shell
+kubectl describe policy <NAME>
 . . .
 Status:
   Message:  Configuration for default/webapp-policy was added or updated
@@ -144,16 +144,16 @@ The following fields are reported in Policy status:
 A TransportServer resource includes the status field with information about the state of the resource.
 You can see the status in the output of the `kubectl get transportserver` command as shown below:
 
-```
-$ kubectl get transportserver
+```shell
+kubectl get transportserver
   NAME      STATE   REASON           AGE
   dns-tcp   Valid   AddedOrUpdated   47m
 ```
 
 In order to see additional addresses or extra information about the `Status` of the resource, use the following command:
 
-```
-$ kubectl describe transportserver <NAME>
+```shell
+kubectl describe transportserver <NAME>
 . . .
 Status:
   Message:  Configuration for default/dns-tcp was added or updated

docs/content/configuration/handling-host-and-listener-collisions.md

@@ -56,7 +56,7 @@ If a user creates both resources in the cluster, a host collision will occur. As
 
 In our example, if `cafe-virtual-server` was created first, it will win the host `cafe.example.com` and the Ingress Controller will reject `cafe-ingress`. This will be reflected in the events and in the resource's status field:
 
-```console
+```shell
 kubectl describe vs cafe-virtual-server
 
 . . .
@@ -130,7 +130,7 @@ If a user creates both resources in the cluster, a listener collision will occur
 
 In our example, if `tcp-1` was created first, it will win the listener `dns-tcp` and the Ingress Controller will reject `tcp-2`. This will be reflected in the events and in the resource's status field:
 
-```console
+```shell
 kubectl describe ts tcp-2
 
 . . .

docs/content/configuration/ingress-resources/advanced-configuration-with-annotations.md

@@ -57,7 +57,7 @@ NGINX Ingress Controller validates the annotations of Ingress resources. If an I
 
 You can check if the Ingress Controller successfully applied the configuration for an Ingress. For our example `cafe-ingress-with-annotations` Ingress, we can run:
 
-```console
+```shell
 kubectl describe ing cafe-ingress-with-annotations
 
 . . .
@@ -71,7 +71,7 @@ Note how the events section includes a Normal event with the AddedOrUpdated reas
 
 If you create an invalid Ingress, the Ingress Controller will reject it and emit a Rejected event. For example, if you create an Ingress `cafe-ingress-with-annotations`, with an annotation `nginx.org/redirect-to-https` set to `yes please` instead of `true`, you will get:
 
-```console
+```shell
 kubectl describe ing cafe-ingress-with-annotations
 
 . . .

docs/content/configuration/ingress-resources/advanced-configuration-with-snippets.md

@@ -104,7 +104,7 @@ If a snippet includes an invalid NGINX configuration, the Ingress Controller wil
 
 An example of an error from the logs:
 
-```
+```shell
 [emerg] 31#31: unknown directive "badd_header" in /etc/nginx/conf.d/default-cafe-ingress-with-snippets.conf:54
 Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"cafe-ingress-with-snippets", UID:"f9656dc9-63a6-41dd-a499-525b0e0309bb", APIVersion:"extensions/v1beta1", ResourceVersion:"2322030", FieldPath:""}): type: 'Warning' reason: 'AddedOrUpdatedWithError' Configuration for default/cafe-ingress-with-snippets was added or updated, but not applied: Error reloading NGINX for default/cafe-ingress-with-snippets: nginx reload failed: Command /usr/sbin/nginx -s reload stdout: ""
 stderr: "nginx: [emerg] unknown directive \"badd_header\" in /etc/nginx/conf.d/default-cafe-ingress-with-snippets.conf:54\n"
@@ -113,7 +113,7 @@ finished with error: exit status 1
 
 An example of an event with an error (you can view events associated with the Ingress by running `kubectl describe -n nginx-ingress ingress nginx-ingress`):
 
-```
+```shell
 Events:
 Type     Reason                   Age                From                      Message
 ----     ------                   ----               ----                      -------

docs/content/configuration/ingress-resources/custom-annotations.md

@@ -57,7 +57,7 @@ spec:
 
 Assuming that the Ingress Controller is using that customized template, it will generate a config for the Ingress resource that will include the following part, generated by our template excerpt:
 
-```
+```yaml
 # This is the configuration for cafe-ingress/default
 
 # Insert config for feature A if the annotation is set

docs/content/configuration/policy-resource.md

@@ -501,15 +501,15 @@ You can use the usual `kubectl` commands to work with Policy resources, just as
 
 For example, the following command creates a Policy resource defined in `access-control-policy-allow.yaml` with the name `webapp-policy`:
 
-```console
+```shell
 kubectl apply -f access-control-policy-allow.yaml
 
 policy.k8s.nginx.org/webapp-policy configured
 ```
 
 You can get the resource by running:
 
-```console
+```shell
 kubectl get policy webapp-policy
 
 NAME            AGE
@@ -669,15 +669,15 @@ If you try to create (or update) a resource that violates the structural schema
 
 - Example of `kubectl` validation:
 
-    ```console
+    ```shell
     kubectl apply -f access-control-policy-allow.yaml
 
     error: error validating "access-control-policy-allow.yaml": error validating data: ValidationError(Policy.spec.accessControl.allow): invalid type for org.nginx.k8s.v1.Policy.spec.accessControl.allow: got "string", expected "array"; if you choose to ignore these errors, turn validation off with --validate=false
     ```
 
 - Example of Kubernetes API server validation:
 
-    ```console
+    ```shell
     kubectl apply -f access-control-policy-allow.yaml --validate=false
 
     The Policy "webapp-policy" is invalid: spec.accessControl.allow: Invalid value: "string": spec.accessControl.allow in body must be of type array: "string"
@@ -691,7 +691,7 @@ NGINX Ingress Controller validates the fields of a Policy resource. If a resourc
 
 You can use `kubectl` to check whether or not NGINX Ingress Controller successfully applied a Policy configuration. For our example `webapp-policy` Policy, we can run:
 
-```console
+```shell
 kubectl describe pol webapp-policy
 
 . . .
@@ -705,7 +705,7 @@ Note how the events section includes a Normal event with the AddedOrUpdated reas
 
 If you create an invalid resource, NGINX Ingress Controller will reject it and emit a Rejected event. For example, if you create a Policy `webapp-policy` with an invalid IP `10.0.0.` in the `allow` field, you will get:
 
-```console
+```shell
 kubectl describe policy webapp-policy
 
 . . .
@@ -719,7 +719,7 @@ Note how the events section includes a Warning event with the Rejected reason.
 
 Additionally, this information is also available in the `status` field of the Policy resource. Note the Status section of the Policy:
 
-```console
+```shell
 kubectl describe pol webapp-policy
 
 . . .

docs/content/configuration/transportserver-resource.md

@@ -278,15 +278,15 @@ You can use the usual `kubectl` commands to work with TransportServer resources,
 
 For example, the following command creates a TransportServer resource defined in `transport-server-passthrough.yaml` with the name `secure-app`:
 
-```console
+```shell
 kubectl apply -f transport-server-passthrough.yaml
 
 transportserver.k8s.nginx.org/secure-app created
 ```
 
 You can get the resource by running:
 
-```console
+```shell
 kubectl get transportserver secure-app
 
 NAME         AGE
@@ -363,15 +363,15 @@ If you try to create (or update) a resource that violates the structural schema
 
 - Example of `kubectl` validation:
 
-    ```console
+    ```shell
     kubectl apply -f transport-server-passthrough.yaml
 
       error: error validating "transport-server-passthrough.yaml": error validating data: ValidationError(TransportServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.TransportServer.spec.upstreams.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false
     ```
 
 - Example of Kubernetes API server validation:
 
-    ```console
+    ```shell
     kubectl apply -f transport-server-passthrough.yaml --validate=false
 
       The TransportServer "secure-app" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list:
@@ -386,7 +386,7 @@ The Ingress Controller validates the fields of a TransportServer resource. If a
 
 You can check if the Ingress Controller successfully applied the configuration for a TransportServer. For our example `secure-app` TransportServer, we can run:
 
-```console
+```shell
 kubectl describe ts secure-app
 
 . . .
@@ -400,7 +400,7 @@ Note how the events section includes a Normal event with the AddedOrUpdated reas
 
 If you create an invalid resource, the Ingress Controller will reject it and emit a Rejected event. For example, if you create a TransportServer `secure-app` with a pass action that references a non-existing upstream, you will get  :
 
-```console
+```shell
 kubectl describe ts secure-app
 
 . . .

docs/content/configuration/virtualserver-and-virtualserverroute-resources.md

@@ -936,15 +936,15 @@ You can use the usual `kubectl` commands to work with VirtualServer and VirtualS
 
 For example, the following command creates a VirtualServer resource defined in `cafe-virtual-server.yaml` with the name `cafe`:
 
-```console
+```shell
 kubectl apply -f cafe-virtual-server.yaml
 
 virtualserver.k8s.nginx.org "cafe" created
 ```
 
 You can get the resource by running:
 
-```console
+```shell
 kubectl get virtualserver cafe
 
 NAME   STATE   HOST                   IP            PORTS      AGE
@@ -1024,15 +1024,15 @@ If you try to create (or update) a resource that violates the structural schema
 
 - Example of `kubectl` validation:
 
-    ```console
+    ```shell
     kubectl apply -f cafe-virtual-server.yaml
 
       error: error validating "cafe-virtual-server.yaml": error validating data: ValidationError(VirtualServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false
     ```
 
 - Example of Kubernetes API server validation:
 
-    ```console
+    ```shell
     kubectl apply -f cafe-virtual-server.yaml --validate=false
 
       The VirtualServer "cafe" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list:
@@ -1047,7 +1047,7 @@ The Ingress Controller validates the fields of the VirtualServer and VirtualServ
 
 You can check if the Ingress Controller successfully applied the configuration for a VirtualServer. For our example `cafe` VirtualServer, we can run:
 
-```console
+```shell
 kubectl describe vs cafe
 
 . . .
@@ -1061,7 +1061,7 @@ Note how the events section includes a Normal event with the AddedOrUpdated reas
 
 If you create an invalid resource, the Ingress Controller will reject it and emit a Rejected event. For example, if you create a VirtualServer `cafe` with two upstream with the same name `tea`, you will get:
 
-```console
+```shell
 kubectl describe vs cafe
 
 . . .
@@ -1075,7 +1075,7 @@ Note how the events section includes a Warning event with the Rejected reason.
 
 Additionally, this information is also available in the `status` field of the VirtualServer resource. Note the Status section of the VirtualServer:
 
-```console
+```shell
 kubectl describe vs cafe
 
 . . .

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

@@ -38,7 +38,7 @@ kubectl apply -f crds/
 
 Alternatively, CRDs can be upgraded without pulling the chart by running:
 
-```console
+```shell
 kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds.yaml
 ```
 

docs/content/installation/integrations/app-protect-dos/dos-protected.md

@@ -27,7 +27,6 @@ spec:
   name: "my-dos"
   apDosMonitor:
     uri: "webapp.example.com"
-
 ```
 
 {{% table %}}
@@ -95,8 +94,8 @@ The Ingress Controller validates the fields of a dos protected resource. If a re
 
 You can use `kubectl` to check if the Ingress Controller successfully applied a dos protected resource configuration. For our example `dos-protected` dos protected resource, we can run:
 
-```
-$ kubectl describe dosprotectedresource dos-protected
+```shell
+kubectl describe dosprotectedresource dos-protected
 . . .
 Events:
   Type    Reason          Age                From                      Message
@@ -108,8 +107,8 @@ Note how the events section includes a Normal event with the AddedOrUpdated reas
 
 If you create an invalid resource, the Ingress Controller will reject it and emit a Rejected event. For example, if you create a dos protected resource `dos-protected` with an invalid URI `bad` in the `dosSecurityLog/dosLogDest` field, you will get:
 
-```
-$ kubectl describe policy webapp-policy
+```shell
+kubectl describe policy webapp-policy
 . . .
 Events:
   Type     Reason    Age   From                      Message