From 331cc6fee0c6edb4980dc26717af165090cb7057 Mon Sep 17 00:00:00 2001 From: Duffie Cooley Date: Wed, 9 Oct 2019 16:44:51 -0700 Subject: [PATCH] Minor doc fix for syntax and typo (#16666) * Minor doc fix for syntax and typo Signed-off-by: Duffie Cooley * Feedback from sftim --- .../tools/kubeadm/high-availability.md | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index b633b4726f88a..1205ddfef68f0 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -114,21 +114,21 @@ option. Your cluster requirements may need a different configuration. - The `--upload-certs` flag is used to upload the certificates that should be shared across all the control-plane instances to the cluster. If instead, you prefer to copy certs across control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual - certificate distribution](#manual-certs) section bellow. + certificate distribution](#manual-certs) section below. -{{< note >}} -The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want -to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). -{{< /note >}} + {{< note >}} + The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want + to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). + {{< /note >}} -{{< note >}} -Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and -some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). -To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file -set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. -{{< /note >}} + {{< note >}} + Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and + some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). + To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file + set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. + {{< /note >}} -After the command completes you should see something like so: + - The output looks similar to: ```sh ... @@ -142,30 +142,30 @@ Then you can join any number of worker nodes by running the following on each as 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. -- 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 -node that is already joined 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 + node that is already joined to the cluster: ```sh sudo kubeadm init phase upload-certs --upload-certs ``` -- You can also specify a custom `--certificate-key` during `init` that can later be used by `join`. -To generate such a key you can use the following command: + - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`. + To generate such a key you can use the following command: ```sh kubeadm alpha certs certificate-key ``` -{{< note >}} -The `kubeadm-certs` Secret and decryption key expire after two hours. -{{< /note >}} + {{< note >}} + The `kubeadm-certs` Secret and decryption key expire after two hours. + {{< /note >}} -{{< caution >}} -As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret! -{{< /caution >}} + {{< caution >}} + As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret! + {{< /caution >}} 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. @@ -244,19 +244,19 @@ in the kubeadm config file. 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. -{{< /note >}} + {{< 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. + {{< /note >}} - - Replace the following variables in the config template with the appropriate values for your cluster: + - Replace the following variables in the config template with the appropriate values for your cluster: - - `LOAD_BALANCER_DNS` - - `LOAD_BALANCER_PORT` - - `ETCD_0_IP` - - `ETCD_1_IP` - - `ETCD_2_IP` + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` The following steps are similar to the stacked etcd setup: @@ -349,11 +349,11 @@ SSH is required if you want to control all nodes from a single machine. done ``` -{{< caution >}} -Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates -with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake, -the creation of additional nodes could fail due to a lack of required SANs. -{{< /caution >}} + {{< caution >}} + Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates + with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake, + the creation of additional nodes could fail due to a lack of required SANs. + {{< /caution >}} 1. Then on each joining control plane node you have to run the following script before running `kubeadm join`. This script will move the previously copied certificates from the home directory to `/etc/kubernetes/pki`: