mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-21 22:07:13 +00:00
0e7c05757f
Unless k3s is front-of-mind when you're on this slide, I suspect attendees might benefit from a link here?
90 lines
2.2 KiB
Markdown
90 lines
2.2 KiB
Markdown
# API server availability
|
|
|
|
- When we set up a node, we need the address of the API server:
|
|
|
|
- for kubelet
|
|
|
|
- for kube-proxy
|
|
|
|
- sometimes for the pod network system (like kube-router)
|
|
|
|
- How do we ensure the availability of that endpoint?
|
|
|
|
(what if the node running the API server goes down?)
|
|
|
|
---
|
|
|
|
## Option 1: external load balancer
|
|
|
|
- Set up an external load balancer
|
|
|
|
- Point kubelet (and other components) to that load balancer
|
|
|
|
- Put the node(s) running the API server behind that load balancer
|
|
|
|
- Update the load balancer if/when an API server node needs to be replaced
|
|
|
|
- On cloud infrastructures, some mechanisms provide automation for this
|
|
|
|
(e.g. on AWS, an Elastic Load Balancer + Auto Scaling Group)
|
|
|
|
- [Example in Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md#the-kubernetes-frontend-load-balancer)
|
|
|
|
---
|
|
|
|
## Option 2: local load balancer
|
|
|
|
- Set up a load balancer (like NGINX, HAProxy...) on *each* node
|
|
|
|
- Configure that load balancer to send traffic to the API server node(s)
|
|
|
|
- Point kubelet (and other components) to `localhost`
|
|
|
|
- Update the load balancer configuration when API server nodes are updated
|
|
|
|
---
|
|
|
|
## Updating the local load balancer config
|
|
|
|
- Distribute the updated configuration (push)
|
|
|
|
- Or regularly check for updates (pull)
|
|
|
|
- The latter requires an external, highly available store
|
|
|
|
(it could be an object store, an HTTP server, or even DNS...)
|
|
|
|
- Updates can be facilitated by a DaemonSet
|
|
|
|
(but remember that it can't be used when installing a new node!)
|
|
|
|
---
|
|
|
|
## Option 3: DNS records
|
|
|
|
- Put all the API server nodes behind a round-robin DNS
|
|
|
|
- Point kubelet (and other components) to that name
|
|
|
|
- Update the records when needed
|
|
|
|
- Note: this option is not officially supported
|
|
|
|
(but since kubelet supports reconnection anyway, it *should* work)
|
|
|
|
---
|
|
|
|
## Option 4: ....................
|
|
|
|
- Many managed clusters expose a high-availability API endpoint
|
|
|
|
(and you don't have to worry about it)
|
|
|
|
- You can also use HA mechanisms that you're familiar with
|
|
|
|
(e.g. virtual IPs)
|
|
|
|
- Tunnels are also fine
|
|
|
|
(e.g. [k3s](https://k3s.io/) uses a tunnel to allow each node to contact the API server)
|