Baremetal Local Multi Master
Los requisitos necesarios:
sudo apt-get install vagrant
sudo apt-get install virtualbox
En versiones más recientes de VirtualBox, necesité modificar la configuración para liberar el rango de IPs.
sudo mkdir /etc/vbox
sudo echo "* 10.0.0.0/8 192.168.0.0/16" >> /etc/vbox/networks.conf
sudo echo "* 2001::/64" >> /etc/vbox/networks.conf
La topología propuesta aquí sigue el siguiente proyecto de Kubernetes. https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/ 
Para esta instalación vamos a configurar 3 nodos masters, 2 nodos workers y 2 load balancers utilizando HAProxy.
El motivo para 2 load balancers es que si solo existe uno y falla, toda la comunicación con el clúster también se pierde.
¿De qué sirve tener alta disponibilidad para los nodos masters si no existe para el load balancer?
Para crear la alta disponibilidad también con el load balancer se usará Keepalived.
Para el uso del load balancer vamos a utilizar HAProxy.
Analizando el diagrama abajo es posible entender mejor lo que haremos. 
El archivo Vagrantfile contiene la configuración de las máquinas y las llamadas de los scripts necesarios para la instalación.
Explicando el Vagrantfile
Todas las máquinas ejecutarán el script bootstrap_ssh.sh
Este script no hace más que copiar las claves dentro de files para los usuarios dentro de la VM y autorizar la clave para acceso con el comando vagrant ssh <nombre de la máquina>
Las máquinas creadas son loadbalancer1, loadbalancer2, master1, master2, master3, worker1, worker2.
Es posible tener hasta:
- 239 workers(10.10.10.1 hasta 10.10.10.239)
- 9 masters (10.10.10.241 hasta 10.10.10.249)
- 4 load balancers 10.10.10.251 y el siguiente 10.10.10.254
y la dirección 10.10.10.250 quedará reservada para keepalived
La primera parte del vagrantfile es levantar nuestros load balancers (lb) pues será el enlace entre los masters y workers.
El archivo responsable por esta configuración es bootstrap_lb.sh que será ejecutado solamente en las máquinas load balancers.
Obs:
Los load balancers no forman parte del clúster kubernetes.
Todos los otros nodos que formarán parte del clúster kubernetes ejecutan bootstrap_nodes, sean masters o workers. Este script contiene la instalación de containerd y los binarios de kubernetes, así como algunos requisitos necesarios que están en la documentación de kubernetes.
La ejecución del primer master (10.10.10.241) estará separada de los demás, pues solo él hará el init del clúster, los demás solamente harán el join dentro del clúster.
El archivo bootstrap.sh será el script que todos los nodos necesitan ejecutar al final del despliegue de cada uno de los nodos.
Por último, si analizas el vagrantfile, en caso de ser master ejecutará el script bootstrap_master.sh y en caso de ser worker ejecutará el script bootstrap_worker.sh.
En el script para el master crea el clúster y guarda el comando join en un ejecutable para que el worker ejecute el mismo a través de ssh hacia el master.
Comandos básicos de vagrant
Las máquinas definidas en el vagrant file son: loadbalancer1, loadbalancer2, master1, master2, master3, worker1, y worker2
Iniciar todas las máquinas. Paciencia...
vagrant up
Destruir todas las máquinas.
vagrant destroy
Iniciar una máquina específica.
vagrant up master
Destruir una máquina específica.
vagrant destroy worker1
Apagar todas las máquinas.
vagrant halt
Apagar una máquina específica.
vagrant halt worker1
Entrar en una máquina utilizando ssh
vagrant ssh master
Pruebas propuestas
Realiza algunas pruebas para verificar la alta disponibilidad.
Verifica keepalived en loadbalancer1 y en loadbalancer2
vagrant ssh loadbalancer1 # para entrar en la máquina
ip -c -br a # ya dentro de la máquina para verificar las interfaces de red
 Observa que se creó una red virtual en loadbalancer1. Esta red virtual no está presente en loadbalancer2, pues ya fue declarada en loadbalancer1.
Detén loadbalancer1 (vagrant halt loadbalancer1) y verifica si todo sigue funcionando. Debería estar funcionando pues fue para eso que creamos los dos load balancers. También verifica que la red virtual ahora está presente en loadbalancer2 (vagrant ssh loadbalancer2 y después ip -c -br a).
Detén loadbalancer2 (vagrant halt loadbalancer2) y verifica que el clúster falla haciendo un kubectl get nodes dentro de alguno de los masters. Después levanta nuevamente los load balancers (vagrant up loadbalancer1 y vagrant up loadbalancer2) y verifica si todo vuelve a funcionar haciendo el mismo comando get nodes.
Detén un master (vagrant halt master1) y verifica si todo está funcionando todavía. En este caso quedarás con 2 masters. Entra en alguno de ellos (vagrant ssh master3) y ejecuta kubectl get nodes para ver si hay respuesta. Tiene que funcionar...
Ahora detén un master más (vagrant halt master2) y observa qué sucede si de 3 masters te quedas solo con 1. Ejecuta kubectl get nodes en master3.
¿Debería funcionar? No, por causa del protocolo de consenso. Él no sabe si cayó él o si cayó el otro. Estudia nuevamente el consenso para entender sobre el quorum.
Levanta uno de los masters (vagrant up master2) que detuviste y verifica si vuelve a funcionar... Tiene que volver...