kubeadm: update the docs for HA with --control-plane-endpoint (#15369)

The addition of the flag "---control-plane-endpoint" for
"kubeadm init" removes the requirement for creating a config file
for the stacked etcd setup.

The config is still required for stacked etcd setup.
This commit is contained in:
Lubomir I. Ivanov
2019-07-22 17:06:52 +03:00
committed by Kubernetes Prow Robot
parent 024dadf012
commit e75c348dbe
@@ -100,41 +100,38 @@ option. Your cluster requirements may need a different configuration.
### Steps for the first control plane node ### 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 ```sh
kind: ClusterConfiguration sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
kubernetesVersion: stable ```
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
- `kubernetesVersion` should be set to the Kubernetes version to use. This - You can use the `--kubernetes-version` flag to set the Kubernetes version to use.
example uses `stable`. It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
- `controlPlaneEndpoint` should match the address or DNS and port of the load balancer. - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer.
- It's recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. - 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 >}} {{< note >}}
Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and 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). 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 To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
the `networking` object of `ClusterConfiguration`. set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
{{< /note >}} {{< /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: After the command completes you should see something like so:
```sh ```sh
... ...
You can now join any number of control-plane node by running the following command on each as a root: 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! 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. 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 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 >}} {{< note >}}
The `kubeadm-certs` Secret and decryption key expire after two hours. The `kubeadm-certs` Secret and decryption key expire after two hours.
{{< /note >}} {{< /note >}}
{{< caution >}} {{< 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 >}} {{< /caution >}}
1. Apply the CNI plugin of your choice: 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 keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
{{< note >}} {{< note >}}
The difference between stacked etcd and external etcd here is that we are using The difference between stacked etcd and external etcd here is that the external etcd setup requires
the `external` field for `etcd` in the kubeadm config. In the case of the stacked a configuration file with the etcd endpoints under the `external` object for `etcd`.
etcd topology this is managed automatically. In the case of the stacked etcd topology this is managed automatically.
{{< /note >}} {{< /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:
@@ -264,7 +256,7 @@ etcd topology this is managed automatically.
- `ETCD_1_IP` - `ETCD_1_IP`
- `ETCD_2_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. 1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node.