Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up the kubeadm high availability instructions. Fixes Issue 15284 #15411

Closed
wants to merge 5 commits into from
Closed
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ For both methods you need this infrastructure:
the masters
- Three machines that meet [kubeadm's minimum
requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
- A highly available load balancer that operates at Layer 4 (such as one provided by a cloud provider, or [HAProxy](http://www.haproxy.org/)) with it's own name in DNS. The load balancer should be configured to forward the apiserver port (default: 6443) on the load balancer to the apiserver port on all control plane nodes. Before using a cloud provider provided load balancer, double check the documentation for [NAT hairpinning](https://en.wikipedia.org/wiki/Hairpinning) support.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably mention HTTPS and health checks here.
@ereslibre @fabriziopandini how would you word that?

Copy link
Contributor

@ereslibre ereslibre Jul 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that even if it's a layer 4 LB it should have the ability to perform HTTPS health checks (even if the certificate chain is ignored) against every apiserver /healthz endpoint. That way it will remove from the active pool unhealthy apiservers.

rcythr marked this conversation as resolved.
Show resolved Hide resolved
- Full network connectivity between all machines in the cluster (public or
private network)
- sudo privileges on all machines
Expand All @@ -54,48 +55,6 @@ For the external etcd cluster only, you also need:

{{% capture steps %}}

## First steps for both methods

### Create load balancer for kube-apiserver

{{< note >}}
There are many configurations for load balancers. The following example is only one
option. Your cluster requirements may need a different configuration.
{{< /note >}}

1. Create a kube-apiserver load balancer with a name that resolves to DNS.

- In a cloud environment you should place your control plane nodes behind a TCP
forwarding load balancer. This load balancer distributes traffic to all
healthy control plane nodes in its target list. The health check for
an apiserver is a TCP check on the port the kube-apiserver listens on
(default value `:6443`).

- It is not recommended to use an IP address directly in a cloud environment.

- The load balancer must be able to communicate with all control plane nodes
on the apiserver port. It must also allow incoming traffic on its
listening port.

- [HAProxy](http://www.haproxy.org/) can be used as a load balancer.

- Make sure the address of the load balancer always matches
the address of kubeadm's `ControlPlaneEndpoint`.

1. Add the first control plane nodes to the load balancer and test the
connection:

```sh
nc -v LOAD_BALANCER_IP PORT
```

- A connection refused error is expected because the apiserver 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.

1. Add the remaining control plane nodes to the load balancer target group.

## Stacked control plane and etcd nodes

### Steps for the first control plane node
Expand Down