fix docs/<file>.md errors identified by markdownlint

*	docs/azure-csi.md
* docs/azure.md
* docs/bootstrap-os.md
*	docs/calico.md
* docs/debian.md
* docs/fcos.md
*	docs/vagrant.md
* docs/gcp-lb.md
* docs/kubernetes-apps/registry.md
* docs/setting-up-your-first-cluster.md
* docs/vagrant.md
*	docs/vars.md

docs/azure-csi.md

@@ -57,19 +57,28 @@ The name of the network security group your instances are in, can be retrieved v
 These will have to be generated first:
 
 - Create an Azure AD Application with:
-`az ad app create --display-name kubespray --identifier-uris http://kubespray --homepage http://kubespray.com --password CLIENT_SECRET`
+
+  ```ShellSession
+  az ad app create --display-name kubespray --identifier-uris http://kubespray --homepage http://kubespray.com --password CLIENT_SECRET
+  ```
 
 Display name, identifier-uri, homepage and the password can be chosen
 
 Note the AppId in the output.
 
 - Create Service principal for the application with:
-`az ad sp create --id AppId`
+
+  ```ShellSession
+  az ad sp create --id AppId
+  ```
 
 This is the AppId from the last command
 
 - Create the role assignment with:
-`az role assignment create --role "Owner" --assignee http://kubespray --subscription SUBSCRIPTION_ID`
+
+  ```ShellSession
+  az role assignment create --role "Owner" --assignee http://kubespray --subscription SUBSCRIPTION_ID
+  ```
 
 azure\_csi\_aad\_client\_id must be set to the AppId, azure\_csi\_aad\_client\_secret is your chosen secret.
 

docs/azure.md

@@ -71,14 +71,27 @@ The name of the resource group that contains the route table.  Defaults to `azur
 These will have to be generated first:
 
 - Create an Azure AD Application with:
-`az ad app create --display-name kubernetes --identifier-uris http://kubernetes --homepage http://example.com --password CLIENT_SECRET`
+
+  ```ShellSession
+   az ad app create --display-name kubernetes --identifier-uris http://kubernetes --homepage http://example.com --password CLIENT_SECRET
+  ```
+
 display name, identifier-uri, homepage and the password can be chosen
 Note the AppId in the output.
+
 - Create Service principal for the application with:
-`az ad sp create --id AppId`
+
+  ```ShellSession
+  az ad sp create --id AppId
+  ```
+
 This is the AppId from the last command
+
 - Create the role assignment with:
-`az role assignment create --role "Owner" --assignee http://kubernetes --subscription SUBSCRIPTION_ID`
+
+  ```ShellSession
+  az role assignment create --role "Owner" --assignee http://kubernetes --subscription SUBSCRIPTION_ID
+  ```
 
 azure\_aad\_client\_id must be set to the AppId, azure\_aad\_client\_secret is your chosen secret.
 

docs/bootstrap-os.md

@@ -48,11 +48,13 @@ The `kubespray-defaults` role is expected to be run before this role.
 
 Remember to disable fact gathering since Python might not be present on hosts.
 
-    - hosts: all
+```yaml
+- hosts: all
   gather_facts: false  # not all hosts might be able to run modules yet
   roles:
     - kubespray-defaults
     - bootstrap-os
+```
 
 ## License
 

docs/calico.md

@@ -124,8 +124,7 @@ You need to edit your inventory and add:
 * `calico_rr` group with nodes in it. `calico_rr` can be combined with
   `kube_node` and/or `kube_control_plane`. `calico_rr` group also must be a child
    group of `k8s_cluster` group.
-* `cluster_id` by route reflector node/group (see details
+* `cluster_id` by route reflector node/group (see details [here](https://hub.docker.com/r/calico/routereflector/))
-[here](https://hub.docker.com/r/calico/routereflector/))
 
 Here's an example of Kubespray inventory with standalone route reflectors:
 

docs/debian.md

@@ -4,9 +4,11 @@ Debian Jessie installation Notes:
 
 - Add
 
-  ```GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"```
+  ```ini
+  GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"
+  ```
 
-  to /etc/default/grub. Then update with
+  to `/etc/default/grub`. Then update with
 
   ```ShellSession
   sudo update-grub
@@ -16,7 +18,9 @@ Debian Jessie installation Notes:
 
 - Add the [backports](https://backports.debian.org/Instructions/) which contain Systemd 2.30 and update Systemd.
 
-  ```apt-get -t jessie-backports install systemd```
+  ```ShellSession
+  apt-get -t jessie-backports install systemd
+  ```
 
   (Necessary because the default Systemd version (2.15) does not support the "Delegate" directive in service files)
 
@@ -26,11 +30,12 @@ Debian Jessie installation Notes:
   sudo add-apt-repository ppa:ansible/ansible
   sudo apt-get update
   sudo apt-get install ansible
-
   ```
 
 - Install Jinja2 and Python-Netaddr
 
-  ```sudo apt-get install python-jinja2=2.8-1~bpo8+1 python-netaddr```
+  ```ShellSession
+  sudo apt-get install python-jinja2=2.8-1~bpo8+1 python-netaddr
+  ```
 
 Now you can continue with [Preparing your deployment](getting-started.md#starting-custom-deployment)

docs/fcos.md

@@ -54,7 +54,7 @@ Prepare ignition and serve via http (a.e. python -m http.server )
 
 ### create guest
 
-```shell script
+```ShellSeasion
 machine_name=myfcos1
 ignition_url=http://mywebserver/fcos.ign
 

docs/gcp-lb.md

@@ -2,15 +2,19 @@
 
 Google Cloud Platform can be used for creation of Kubernetes Service Load Balancer.
 
-This feature is able to deliver by adding parameters to kube-controller-manager and kubelet. You need specify:
+This feature is able to deliver by adding parameters to `kube-controller-manager` and `kubelet`. You need specify:
 
+```
     --cloud-provider=gce
     --cloud-config=/etc/kubernetes/cloud-config
+```
 
-To get working it in kubespray, you need to add tag to GCE instances and specify it in kubespray group vars and also set cloud_provider to gce. So for example, in file group_vars/all/gcp.yml:
+To get working it in kubespray, you need to add tag to GCE instances and specify it in kubespray group vars and also set `cloud_provider` to `gce`. So for example, in file `group_vars/all/gcp.yml`:
 
+```
     cloud_provider: gce
     gce_node_tags: k8s-lb
+```
 
-When you will setup it and create SVC in Kubernetes with type=LoadBalancer, cloud provider will create public IP and will set firewall.
+When you will setup it and create SVC in Kubernetes with `type=LoadBalancer`, cloud provider will create public IP and will set firewall.
 Note: Cloud provider run under VM service account, so this account needs to have correct permissions to be able to create all GCP resources.

docs/kubernetes-apps/registry.md

@@ -29,8 +29,7 @@ use Kubernetes's `PersistentVolume` abstraction. The following template is
 expanded by `salt` in the GCE cluster turnup, but can easily be adapted to
 other situations:
 
-<!-- BEGIN MUNGE: EXAMPLE registry-pv.yaml.in -->
+```yaml
-``` yaml
 kind: PersistentVolume
 apiVersion: v1
 metadata:
@@ -46,7 +45,6 @@ spec:
     fsType: "ext4"
 {% endif %}
 ```
-<!-- END MUNGE: EXAMPLE registry-pv.yaml.in -->
 
 If, for example, you wanted to use NFS you would just need to change the
 `gcePersistentDisk` block to `nfs`. See
@@ -68,8 +66,7 @@ Now that the Kubernetes cluster knows that some storage exists, you can put a
 claim on that storage. As with the `PersistentVolume` above, you can start
 with the `salt` template:
 
-<!-- BEGIN MUNGE: EXAMPLE registry-pvc.yaml.in -->
+```yaml
-``` yaml
 kind: PersistentVolumeClaim
 apiVersion: v1
 metadata:
@@ -82,7 +79,6 @@ spec:
     requests:
       storage: {{ pillar['cluster_registry_disk_size'] }}
 ```
-<!-- END MUNGE: EXAMPLE registry-pvc.yaml.in -->
 
 This tells Kubernetes that you want to use storage, and the `PersistentVolume`
 you created before will be bound to this claim (unless you have other
@@ -93,8 +89,7 @@ gives you the right to use this storage until you release the claim.
 
 Now we can run a Docker registry:
 
-<!-- BEGIN MUNGE: EXAMPLE registry-rc.yaml -->
+```yaml
-``` yaml
 apiVersion: v1
 kind: ReplicationController
 metadata:
@@ -138,7 +133,6 @@ spec:
         persistentVolumeClaim:
           claimName: kube-registry-pvc
 ```
-<!-- END MUNGE: EXAMPLE registry-rc.yaml -->
 
 *Note:* that if you have set multiple replicas, make sure your CSI driver has support for the `ReadWriteMany` accessMode.
 
@@ -146,8 +140,7 @@ spec:
 
 Now that we have a registry `Pod` running, we can expose it as a Service:
 
-<!-- BEGIN MUNGE: EXAMPLE registry-svc.yaml -->
+```yaml
-``` yaml
 apiVersion: v1
 kind: Service
 metadata:
@@ -164,7 +157,6 @@ spec:
     port: 5000
     protocol: TCP
 ```
-<!-- END MUNGE: EXAMPLE registry-svc.yaml -->
 
 ## Expose the registry on each node
 
@@ -172,8 +164,7 @@ Now that we have a running `Service`, we need to expose it onto each Kubernetes
 `Node` so that Docker will see it as `localhost`. We can load a `Pod` on every
 node by creating following daemonset.
 
-<!-- BEGIN MUNGE: EXAMPLE ../../saltbase/salt/kube-registry-proxy/kube-registry-proxy.yaml -->
+```yaml
-``` yaml
 apiVersion: apps/v1
 kind: DaemonSet
 metadata:
@@ -207,7 +198,6 @@ spec:
           containerPort: 80
           hostPort: 5000
 ```
-<!-- END MUNGE: EXAMPLE ../../saltbase/salt/kube-registry-proxy/kube-registry-proxy.yaml -->
 
 When modifying replication-controller, service and daemon-set definitions, take
 care to ensure *unique* identifiers for the rc-svc couple and the daemon-set.
@@ -219,7 +209,7 @@ This ensures that port 5000 on each node is directed to the registry `Service`.
 You should be able to verify that it is running by hitting port 5000 with a web
 browser and getting a 404 error:
 
-``` console
+```ShellSession
 $ curl localhost:5000
 404 page not found
 ```
@@ -229,7 +219,7 @@ $ curl localhost:5000
 To use an image hosted by this registry, simply say this in your `Pod`'s
 `spec.containers[].image` field:
 
-``` yaml
+```yaml
     image: localhost:5000/user/container
 ```
 
@@ -241,7 +231,7 @@ building locally and want to push to your cluster.
 You can use `kubectl` to set up a port-forward from your local node to a
 running Pod:
 
-``` console
+```ShellSession
 $ POD=$(kubectl get pods --namespace kube-system -l k8s-app=registry \
             -o template --template '{{range .items}}{{.metadata.name}} {{.status.phase}}{{"\n"}}{{end}}' \
             | grep Running | head -1 | cut -f1 -d' ')

docs/setting-up-your-first-cluster.md

@@ -252,11 +252,7 @@ Ansible will now execute the playbook, this can take up to 20 minutes.
 We will leverage a kubeconfig file from one of the controller nodes to access
  the cluster as administrator from our local workstation.
 
-> In this simplified set-up, we did not include a load balancer that usually
+> In this simplified set-up, we did not include a load balancer that usually sits on top of the three controller nodes for a high available API server endpoint. In this simplified tutorial we connect directly to one of the three controllers.
- sits on top of the
-three controller nodes for a high available API server endpoint. In this
- simplified tutorial we connect directly to one of the three
- controllers.
 
 First, we need to edit the permission of the kubeconfig file on one of the
 controller nodes:

docs/vagrant.md

@@ -58,7 +58,7 @@ see [download documentation](/docs/downloads.md).
 
 The following is an example of setting up and running kubespray using `vagrant`.
 For repeated runs, you could save the script to a file in the root of the
-kubespray and run it by executing 'source <name_of_the_file>.
+kubespray and run it by executing `source <name_of_the_file>`.
 
 ```ShellSession
 # use virtualenv to install all python requirements