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 ea63a381a6..aa43e00b82 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 @@ -100,41 +100,38 @@ option. Your cluster requirements may need a different configuration. ### Steps for the first control plane node -1. On the first control plane node, create a configuration file called `kubeadm-config.yaml`: +1. Initialize the control plane: - apiVersion: kubeadm.k8s.io/v1beta2 - kind: ClusterConfiguration - kubernetesVersion: stable - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` - - `kubernetesVersion` should be set to the Kubernetes version to use. This - example uses `stable`. - - `controlPlaneEndpoint` should match the address or DNS and port of the load balancer. - - It's recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. + - You can use the `--kubernetes-version` flag to set the Kubernetes version to use. + It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. + - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer. + - 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. + +{{< 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 set the `podSubnet: 192.168.0.0/16` field under -the `networking` object of `ClusterConfiguration`. +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 >}} -1. Initialize the control plane: - - ```sh - sudo kubeadm init --config=kubeadm-config.yaml --upload-certs - ``` - - The `--experimental-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. - After the command completes you should see something like so: ```sh ... You can now join any number of control-plane node by running the following command on each as a root: - kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --experimental-control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 Please note that the certificate-key gives access to cluster sensitive data, keep it secret! As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. @@ -160,17 +157,12 @@ the `networking` object of `ClusterConfiguration`. kubeadm alpha certs certificate-key ``` -{{< 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-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! +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: @@ -251,9 +243,9 @@ in the kubeadm config file. keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key {{< note >}} -The difference between stacked etcd and external etcd here is that we are using -the `external` field for `etcd` in the kubeadm config. In the case of the stacked -etcd topology this is managed automatically. +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: @@ -264,7 +256,7 @@ etcd topology this is managed automatically. - `ETCD_1_IP` - `ETCD_2_IP` -The following steps are exactly the same as described for stacked etcd setup: +The following steps are similar to the stacked etcd setup: 1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node.