Al intentar configurar un clúster de Kubernetes experimental (en algunas máquinas virtuales de mi computadora portátil) como "alta disponibilidad", encontré el consejo de hacerlo usando la combinación de keepalived y haproxy (https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing).
Mirando los ajustes de configuración que leí
${STATE} es MAESTRO para uno y BACKUP para todos los demás hosts, por lo tanto, la IP virtual se asignará inicialmente al MAESTRO.
${PRIORITY} debe ser mayor en el maestro que en las copias de seguridad. Por tanto, 101 y 100 respectivamente serán suficientes.
y estos escenarios me sorprenden. Aparentemente tengo que elegir cuál de esos sistemas será el maestro inicial y tengo que configurarlo "duramente" en los propios nodos.
Para mí, esta configuración de "alta disponibilidad" se desvía de la analogía "mascota"/"ganado" que encuentro en Kubernetes.
Otros sistemas como, por ejemplo, HBase tienen una configuración similar (un líder activo y varios líderes en espera) y todos están configurados "idénticamente" (la elección se realiza a través de ZooKeeper).
¿Hay alguna manera de configurar Keepalived (para usar en Kubernetes) de tal manera que todos los nodos tengan la misma configuración y siga funcionando correctamente?
Respuesta1
El propio Kubernetes proporciona servicios "ganados" a las aplicaciones. Aunque muchos de los servicios "maestros" de Kubernetes se basan en la misma infraestructura, en algún momento es necesario iniciar un servicio con un nivel inferior para que todo se ponga en marcha.
mantener vivocomo está configurado en eldocumento de kubernetes vinculadoproporciona un soloVRRPdirección IP virtual como punto final de alta disponibilidad compartido entre los maestros.
Todos los nodos configuran la misma dirección IP (o nombre) VRRP y keepalived mueve esa dirección entre los maestros. La "elección" se completa en la lógica de conmutación por error y comprobación de estado de keepalived.
Una alternativa a este método es trasladar la decisión de equilibrio de carga a un dispositivo externo o a los clientes. Puede ejecutar un proxy inverso en cada nodo (como haproxy) que puede ponderar los servidores kube-api y completar las comprobaciones de estado.
Respuesta2
Me doy cuenta de que este es un hilo obsoleto, pero pensé en intervenir de todos modos ya que ejecuté KeepaliveD con una configuración idéntica en todos los nodos.
En Debian, tenemos todos los nodos inicialmente configurados en COPIA DE SEGURIDAD y tenemos algún tipo de verificación de estado que aumentará la prioridad (por ejemplo, cuánto tiempo ha estado ejecutándose KeepaliveD o una verificación de salud para el servicio local para el que desea HA...)
VRRP v2, que es lo que KeepaliveD (al menos las versiones con las que he trabajado) ejecuta en Debian, tiene una función de desempate, donde si la prioridad es la misma en varios nodos, entonces gana la "IP más alta".
Esto puede causar un retraso inicial si todos los nodos se inician al mismo tiempo, pero esto ha sido aceptable donde lo usamos.
Espero que ayude.