whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix Markdown formatting

Browse Source
This commit is contained in:
Tim Bannister
2022-01-17 21:38:22 +00:00
parent 62905feb8e
commit 000536e52c
1 changed files with 213 additions and 209 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+32 -28
View File
@@ -12,9 +12,9 @@ This page explains two different approaches to setting up a highly available Kub
cluster using kubeadm: cluster using kubeadm:
- With stacked control plane nodes. This approach requires less infrastructure. The etcd members - With stacked control plane nodes. This approach requires less infrastructure. The etcd members
and control plane nodes are co-located. and control plane nodes are co-located.
- With an external etcd cluster. This approach requires more infrastructure. The - With an external etcd cluster. This approach requires more infrastructure. The
control plane nodes and etcd members are separated. control plane nodes and etcd members are separated.
Before proceeding, you should carefully consider which approach best meets the needs of your applications Before proceeding, you should carefully consider which approach best meets the needs of your applications
and environment. [This comparison topic](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each. and environment. [This comparison topic](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each.
@@ -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) - 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. 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: 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 running. A timeout, however, means the load balancer cannot communicate
with the control plane node. If a timeout occurs, reconfigure the load with the control plane node. If a timeout occurs, reconfigure the load
balancer to communicate with the control plane node. 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`. set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
{{< /note >}} {{< /note >}}
- The output looks similar to: The output looks similar to:
```sh ```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 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 - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
are encrypted and uploaded in the `kubeadm-certs` Secret. 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: node that is already joined to the cluster:
```sh ```sh
@@ -168,7 +170,8 @@ option. Your cluster requirements may need a different configuration.
1. Apply the CNI plugin of your choice: 1. Apply the CNI plugin of your choice:
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) [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 >}} {{< note >}}
You must pick a network plugin that suits your use case and deploy it before you move on to next step. 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 ### 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: 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. 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 - 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. 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 ## External etcd nodes
Setting up a cluster with external etcd nodes is similar to the procedure used for stacked etcd 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 ### 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). 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: 1. Create a file called `kubeadm-config.yaml` with the following contents:
```yaml
---
apiVersion: kubeadm.k8s.io/v1beta3 apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration kind: ClusterConfiguration
kubernetesVersion: stable kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
etcd: etcd:
external: external:
endpoints: 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 caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
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 the external etcd setup requires 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`. 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 >}} {{< /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:
@@ -276,7 +279,7 @@ The steps are the same as for the stacked etcd setup:
- Make sure the first control plane node is fully initialized. - Make sure the first control plane node is fully initialized.
- Join each control plane node with the join command you saved to a text file. It's recommended - Join each control plane node with the join command you saved to a text file. It's recommended
to join the control plane nodes one at a time. to join the control plane nodes one at a time.
- Don't forget that the decryption key from `--certificate-key` expires after two hours, by default. - Don't forget that the decryption key from `--certificate-key` expires after two hours, by default.
## Common tasks after bootstrapping control plane ## Common tasks after bootstrapping control plane
@@ -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 you are going to have to manually copy the certificates from the primary control plane node to the
joining control plane nodes. 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. 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. 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 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 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 In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
other control plane nodes. other control plane nodes.