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
2022-08-07 12:16:58 +00:00 · 2022-08-07 12:16:58 +00:00 · 4a994c82d1
parent b074b91ee9
commit 4a994c82d1
11 changed files with 78 additions and 60 deletions
--- a/docs/azure-csi.md
+++ b/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.

--- a/docs/azure.md
+++ b/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.

--- a/docs/bootstrap-os.md
+++ b/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.

+```yaml
 - hosts: all
  gather_facts: false  # not all hosts might be able to run modules yet
  roles:
    - kubespray-defaults
    - bootstrap-os
+```

 ## License

--- a/docs/calico.md
+++ b/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
-[here](https://hub.docker.com/r/calico/routereflector/))
+* `cluster_id` by route reflector node/group (see details [here](https://hub.docker.com/r/calico/routereflector/))

 Here's an example of Kubespray inventory with standalone route reflectors:

--- a/docs/debian.md
+++ b/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)
--- a/docs/fcos.md
+++ b/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

--- a/docs/gcp-lb.md
+++ b/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.
--- a/docs/kubernetes-apps/registry.md
+++ b/docs/kubernetes-apps/registry.md
@ -29,7 +29,6 @@ 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
 kind: PersistentVolume
 apiVersion: v1
@ -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,7 +66,6 @@ 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
 kind: PersistentVolumeClaim
 apiVersion: v1
@ -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,7 +89,6 @@ 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
 apiVersion: v1
 kind: ReplicationController
@ -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,7 +140,6 @@ spec:

 Now that we have a registry `Pod` running, we can expose it as a Service:

-<!-- BEGIN MUNGE: EXAMPLE registry-svc.yaml -->
 ```yaml
 apiVersion: v1
 kind: Service
@ -164,7 +157,6 @@ spec:
    port: 5000
    protocol: TCP
 ```
-<!-- END MUNGE: EXAMPLE registry-svc.yaml -->

 ## Expose the registry on each node

@ -172,7 +164,6 @@ 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
 apiVersion: apps/v1
 kind: DaemonSet
@ -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
 ```
@ -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' ')
--- a/docs/setting-up-your-first-cluster.md
+++ b/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
- 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.
+> 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.

 First, we need to edit the permission of the kubeconfig file on one of the
 controller nodes:
--- a/docs/vagrant.md
+++ b/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