Fix Markdown formatting

content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md

@@ -80,14 +80,14 @@ option. Your cluster requirements may need a different configuration.
    - Read the [Options for Software Load Balancing](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing)
      guide for more details.
 
-1.  Add the first control plane nodes to the load balancer and test the
+1. Add the first control plane node to the load balancer, and test the
    connection:
 
-    ```sh
+   ```shell
-    nc -v LOAD_BALANCER_IP PORT
+   nc -v <LOAD_BALANCER_IP> <PORT>
    ```
 
-    - A connection refused error is expected because the apiserver is not yet
+   A connection refused error is expected because the API server is not yet
    running. A timeout, however, means the load balancer cannot communicate
    with the control plane node. If a timeout occurs, reconfigure the load
    balancer to communicate with the control plane node.
@@ -127,7 +127,7 @@ option. Your cluster requirements may need a different configuration.
    set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
    {{< /note >}}
 
-    - The output looks similar to:
+   The output looks similar to:
 
    ```sh
    ...
@@ -141,10 +141,12 @@ option. Your cluster requirements may need a different configuration.
        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
    ```
 
-    - Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
+   - Copy this output to a text file. You will need it later to join control plane and worker nodes to
+     the cluster.
    - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
      are encrypted and uploaded in the `kubeadm-certs` Secret.
-    - To re-upload the certificates and generate a new decryption key, use the following command on a control plane
+   - To re-upload the certificates and generate a new decryption key, use the following command on a
+     control plane
      node that is already joined to the cluster:
 
      ```sh
@@ -168,7 +170,8 @@ option. Your cluster requirements may need a different configuration.
 
 1. Apply the CNI plugin of your choice:  
    [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) 
-    to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
+   to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the
+   kubeadm configuration file (if applicable).
 
    {{< note >}}
    You must pick a network plugin that suits your use case and deploy it before you move on to next step.
@@ -183,12 +186,6 @@ option. Your cluster requirements may need a different configuration.
 
 ### Steps for the rest of the control plane nodes
 
-{{< note >}}
-Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel.
-Prior to this version, you must join new control plane nodes sequentially, only after
-the first node has finished initializing.
-{{< /note >}}
-
 For each additional control plane node you should:
 
 1. Execute the join command that was previously given to you by the `kubeadm init` output on the first node.
@@ -202,6 +199,8 @@ For each additional control plane node you should:
    - The `--certificate-key ...` will cause the control plane certificates to be downloaded
      from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.
 
+You can join multiple control-plane nodes in parallel.
+
 ## External etcd nodes
 
 Setting up a cluster with external etcd nodes is similar to the procedure used for stacked etcd
@@ -210,7 +209,7 @@ in the kubeadm config file.
 
 ### Set up the etcd cluster
 
-1.  Follow [these instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster.
+1. Follow these [instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster.
 
 1. Setup SSH as described [here](#manual-certs).
 
@@ -229,24 +228,28 @@ in the kubeadm config file.
 
 1. Create a file called `kubeadm-config.yaml` with the following contents:
 
+
+   ```yaml
+   ---
    apiVersion: kubeadm.k8s.io/v1beta3
    kind: ClusterConfiguration
    kubernetesVersion: stable
-        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+   controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
    etcd:
      external:
        endpoints:
-                - https://ETCD_0_IP:2379
+         - https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
-                - https://ETCD_1_IP:2379
+         - https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
-                - https://ETCD_2_IP:2379
+         - https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
        caFile: /etc/kubernetes/pki/etcd/ca.crt
        certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
        keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+   ```
 
    {{< note >}}
    The difference between stacked etcd and external etcd here is that the external etcd setup requires
    a configuration file with the etcd endpoints under the `external` object for `etcd`.
-  In the case of the stacked etcd topology this is managed automatically.
+   In the case of the stacked etcd topology, this is managed automatically.
    {{< /note >}}
 
    - Replace the following variables in the config template with the appropriate values for your cluster:
@@ -296,7 +299,7 @@ If you choose to not use `kubeadm init` with the `--upload-certs` flag this mean
 you are going to have to manually copy the certificates from the primary control plane node to the
 joining control plane nodes.
 
-There are many ways to do this. In the following example we are using `ssh` and `scp`:
+There are many ways to do this. The following example uses `ssh` and `scp`:
 
 SSH is required if you want to control all nodes from a single machine.
 
@@ -315,7 +318,8 @@ SSH is required if you want to control all nodes from a single machine.
 
 1. SSH between nodes to check that the connection is working correctly.
 
-    - When you SSH to any node, make sure to add the `-A` flag:
+   - When you SSH to any node, add the `-A` flag. This flag allows the node that you
+     have logged into via SSH to access the SSH agent on your PC.
 
      ```
      ssh -A 10.0.0.7
@@ -328,9 +332,9 @@ SSH is required if you want to control all nodes from a single machine.
      sudo -E -s
      ```
 
-1. After configuring SSH on all the nodes you should run the following script on the first control plane node after
+1. After configuring SSH on all the nodes you should run the following script on the first
-   running `kubeadm init`. This script will copy the certificates from the first control plane node to the other
+   control plane node after running `kubeadm init`. This script will copy the certificates from
-   control plane nodes:
+   the first control plane node to the other control plane nodes:
 
    In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
    other control plane nodes.