Me gustaría ampliar mi Kubernetes HA apilado interno con 3 planos de control, 3 nodos de trabajo agrupados en 3 ubicaciones de oficina. Así cada avión de control y 1 trabajador estarían en cada una de las oficinas. Cada plano de control tendría su propia IP estática.
Tengo problemas para entender cómo el equilibrador de carga (estoy usando metallb) podría hacer su trabajo si digamos que la oficina 1 tuviera un corte de energía. ¿Cómo se redirige el tráfico a las oficinas 2 y 3?
por ejemplo, los usuarios externos y públicos que acceden a nextcloud que se ejecuta en office-1-node pueden estar usando un fqdn cloud.company.com que está asociado con la IP estática de office-1-node. (aunque nextcloud puede ejecutarse en un trabajador o maestro en office-2-node, o office-3-node... pero en lo que respecta a los usuarios, no es una preocupación).
Si la oficina-1-nodo tiene un corte de energía, ¿qué dirigiría a cloud.company.com a la IP estática de la oficina-2-nodo o la oficina-3-nodo?
Todavía estoy aprendiendo, así que tenlo en cuenta al responder.
Respuesta1
Pude ver que Metal LB está desplegado (https://metallb.universe.tf/installation/) como controlador (que maneja la asignación de IP) y conjunto de demonios (componente - altavoz -> Creo que esto es el manejo de anuncios externos segúnhttps://metallb.universe.tf/concepts/). Entonces, este LB se implementa básicamente como un recurso de Kubernetes.
En cuanto a su pregunta ahora, si el nodo office-1 tiene una interrupción, los pods en daemonset de otros nodos funcionarán según sea necesario (realizar anuncios externos y hacer que los servicios sean accesibles) y el controlador de sus otros nodos maestros continuará manejando las asignaciones de IP.
Recursos:
- Controlador Kuberneteshttps://kubernetes.io/docs/concepts/architecture/controller/
- Conjunto de demonios de Kuberneteshttps://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
- Manifiesto de Kubernetes Metallb -https://github.com/metallb/metallb/blob/main/manifests/metallb.yaml
Editar: Respondiendo a la pregunta en el segundo comentario. Primero deberá comprar un nombre de dominio (de godaddy, bigrock, AWS Route53, etc.). En segundo lugar, cree un CNAME para señalar ese nombre de dominio a la IP de su balanceador de carga (con puerto opcional) (en su caso, las IP de office-1,2,3 se pueden usar en forma circular para garantizar el tiempo de actividad). Esta modalidad de round robin se llamaEquilibrio de carga DNS. O puedes implementarConmutación por error de DNScomo en AWS Route53 implementando controles de estado en su balanceador de carga. Una vez hecho esto, el usuario externo seguirá teniendo acceso a los servicios en kubernetes (desde office-2 y 3)