Merge pull request #2449 from frandbf/docsstyle

Improve documentation format

docs/deploy/index.md

@@ -167,7 +167,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
 
 This example creates an ELB with just two listeners, one in port 80 and another in port 443
 
-![Listeners](../docs/images/elb-l7-listener.png)
+![Listeners](../images/elb-l7-listener.png)
 
 If the ingress controller uses RBAC run:
 

docs/development.md

@@ -7,7 +7,8 @@ It includes how to build, test, and release ingress controllers.
 
 ### Initial developer environment build
 
-**Prequisites**: Minikube must be installed; See [releases](https://github.com/kubernetes/minikube/releases) for installation instructions. 
+>**Prequisites**: Minikube must be installed.
+See [releases](https://github.com/kubernetes/minikube/releases) for installation instructions. 
 
 If you are using **MacOS** and deploying to **minikube**, the following command will build the local nginx controller container image and deploy the ingress controller onto a minikube cluster with RBAC enabled in the namespace `ingress-nginx`:
 

docs/examples/PREREQUISITES.md

@@ -24,7 +24,7 @@ secret "tls-secret" created
 You can act as your very own CA, or use an existing one. As an exercise / learning, we're going to generate our
 own CA, and also generate a client certificate.
 
-These instructions are based on CoreOS OpenSSL [instructions](https://coreos.com/kubernetes/docs/latest/openssl.html)
+These instructions are based on CoreOS OpenSSL. [See live doc.](https://coreos.com/kubernetes/docs/latest/openssl.html)
 
 ### Generating a CA
 
@@ -119,7 +119,7 @@ the TLS Auth directive:
 $ kubectl create secret generic caingress --namespace=default --from-file=ca.crt=<ca.crt>
 ```
 
-Note: You can also generate the CA Authentication Secret along with the TLS Secret by using:
+__Note:__ You can also generate the CA Authentication Secret along with the TLS Secret by using:
 ```console
 $ kubectl create secret generic caingress --namespace=default --from-file=ca.crt=<ca.crt> --from-file=tls.crt=<tls.crt> --from-file=tls.key=<tls.key>
 ```

docs/examples/docker-registry/README.md

@@ -10,9 +10,10 @@ First we deploy the docker registry in the cluster:
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/examples/docker-registry/deployment.yaml
 ```
 
-**Important:** DO NOT RUN THIS IN PRODUCTION.
-This deployment uses `emptyDir` in the `volumeMount` which means the contents of the registry will be deleted when the pod dies.
+!!! Important
+	**DO NOT RUN THIS IN PRODUCTION**
 
+	This deployment uses `emptyDir` in the `volumeMount` which means the contents of the registry will be deleted when the pod dies.
 
 The next required step is creation of the ingress rules. To do this we have two options: with and without TLS
 
@@ -24,8 +25,10 @@ Download and edit the yaml deployment replacing `registry.<your domain>` with a
 wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/examples/docker-registry/ingress-without-tls.yaml
 ```
 
-**Important:** running a docker registry without TLS requires we configure our local docker daemon with the insecure registry flag.
-Please check [deploy a plain http registry](https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry)
+!!! Important
+	Running a docker registry without TLS requires we configure our local docker daemon with the insecure registry flag.
+
+	Please check [deploy a plain http registry](https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry)
 
 ### With TLS
 

docs/examples/external-auth/README.md

@@ -5,7 +5,8 @@
 The `auth-url` and `auth-signin` annotations allow you to use an external
 authentication provider to protect your Ingress resources.
 
-(Note, this annotation requires `nginx-ingress-controller v0.9.0` or greater.)
+!!! Important
+	this annotation requires `nginx-ingress-controller v0.9.0` or greater.)
 
 ### Key Detail
 
@@ -41,7 +42,7 @@ into a Kubernetes cluster and use it to protect the Kubernetes Dashboard using g
 kubectl create -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/kubernetes-dashboard/v1.5.0.yaml
 ```
 
-2. Create a custom Github OAuth application https://github.com/settings/applications/new
+2. Create a [custom Github OAuth application](https://github.com/settings/applications/new)
 
 ![Register OAuth2 Application](images/register-oauth-app.png)
 

docs/examples/static-ip/README.md

@@ -79,9 +79,9 @@ NAME            HOSTS     ADDRESS           PORTS     AGE
 nginx-ingress   *         104.154.109.191   80, 443   13m
 ```
 
-Note that unlike the GCE Ingress, the same loadbalancer IP is shared amongst all
-Ingresses, because all requests are proxied through the same set of nginx
-controllers.
+> Note that unlike the GCE Ingress, the same loadbalancer IP is shared amongst all
+> Ingresses, because all requests are proxied through the same set of nginx
+> controllers.
 
 ## Promote ephemeral to static IP
 

docs/extra.css

@@ -1,3 +1,3 @@
-td{
+td:nth-child(1){
 	white-space: nowrap;
 }

docs/troubleshooting.md

@@ -170,8 +170,7 @@ The API server will mount a volume containing this file, but only if the API ser
 the ServiceAccount admission controller.
 If you experience this error, verify that your API server is using the ServiceAccount admission controller.
 If you are configuring the API server by hand, you can set this with the `--admission-control` parameter.
-Please note that you should use other admission controllers as well. Before configuring this option, you should
-read about admission controllers.
+> Note that you should use other admission controllers as well. Before configuring this option, you should read about admission controllers.
 
 More information:
 

docs/user-guide/custom-errors.md

@@ -6,7 +6,8 @@ Each request to the default backend includes two headers:
 - `X-Code` indicates the HTTP code to be returned to the client.
 - `X-Format` the value of the `Accept` header.
 
-**Important:** The custom backend must return the correct HTTP status code to be returned. NGINX does not change the response from the custom default backend.
+!!! Important
+	The custom backend must return the correct HTTP status code to be returned. NGINX does not change the response from the custom default backend.
 
 Using these two headers it's possible to use a custom backend service like [this one](https://github.com/kubernetes/ingress-nginx/tree/master/images/custom-error-pages) that inspects each request and returns a custom error page with the format expected by the client. Please check the example [custom-errors](https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/customization/custom-errors).
 

docs/user-guide/miscellaneous.md

@@ -42,7 +42,8 @@ The default value of this 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.
+!!! Important
+	If the NGINX ingress 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)
 

docs/user-guide/multiple-ingress.md

@@ -2,7 +2,9 @@
 
 ## Running multiple ingress controllers
 
-If you're running multiple ingress controllers, or running on a cloud provider that natively handles ingress, you need to specify the annotation `kubernetes.io/ingress.class: "nginx"` in all ingresses that you would like this controller to claim.  This mechanism also provides users the ability to run _multiple_ NGINX ingress controllers (e.g. one which serves public traffic, one which serves "internal" traffic).  When utilizing this functionality the option `--ingress-class` should be changed to a value unique for the cluster within the definition of the replication controller. Here is a partial example:
+If you're running multiple ingress controllers, or running on a cloud provider that natively handles ingress, you need to specify the annotation `kubernetes.io/ingress.class: "nginx"` in all ingresses that you would like this controller to claim.
+
+This mechanism also provides users the ability to run _multiple_ NGINX ingress controllers (e.g. one which serves public traffic, one which serves "internal" traffic).  When utilizing this functionality the option `--ingress-class` should be changed to a value unique for the cluster within the definition of the replication controller. Here is a partial example:
 
 ```
 spec: