Kubernetes - configuração distribuída de alta disponibilidade em três escritórios

Question

Gostaria de estender meu Kubernetes HA empilhado localmente com 3 planos de controle e 3 clusters de nós de trabalho em 3 locais de escritório. Assim, cada plano de controle e 1 trabalhador estariam em cada um dos escritórios. Cada plano de controle teria seu próprio IP estático.

Estou tendo problemas para entender como o balanceador de carga (estou usando o metallb) poderia fazer seu trabalho se digamos que o escritório 1 teve uma queda de energia. Como o tráfego é redirecionado para os escritórios 2 e 3?

Por exemplo, usuários externos e públicos que acessam o nextcloud em execução no nó do escritório 1 podem estar usando um fqdn cloud.company.com associado ao IP estático do nó do escritório 1. (embora o nextcloud possa ser executado em um trabalhador ou mestre no nó de escritório 2 ou nó de escritório 3 ... mas no que diz respeito aos usuários, isso não é uma preocupação.)

Se o nó do escritório 1 sofrer uma queda de energia, o que direcionaria cloud.company.com para o IP estático do nó do escritório 2 ou do nó do escritório 3?

Ainda estou aprendendo, então tenha isso em mente ao responder.

Answer 1

Pude ver que o Metal LB está implantado(https://metallb.universe.tf/installation/) como um controlador (que lida com a atribuição de IP) e daemonset (componente - alto-falante -> Acho que isso é lidar com anúncios externos conformehttps://metallb.universe.tf/concepts/). Portanto, este LB é basicamente implantado como um recurso do Kubernetes.

Chegando à sua pergunta agora, se o nó do escritório 1 tiver uma interrupção, os pods no daemonset de outros nós funcionarão conforme necessário (faça um anúncio externo e torne os serviços acessíveis) e o controlador de seus outros nós mestres continuará a lidar com atribuições de IP.

Recursos:

1. Controlador Kuberneteshttps://kubernetes.io/docs/concepts/architecture/controller/
2. Daemonset Kuberneteshttps://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
3. Manifesto do Kubernetes Metallb -https://github.com/metallb/metallb/blob/main/manifests/metallb.yaml

Editar: respondendo à pergunta no segundo comentário. Primeiro você precisará comprar um nome de domínio (de godaddy, bigrock, AWS Route53, etc). Em segundo lugar, crie um CNAME para apontar esse nome de domínio para o IP do seu balanceador de carga (com porta opcional) (no seu caso, os IPs do office-1,2,3 podem ser usados ​​em round-robin para garantir o tempo de atividade). Essa maneira round robin é chamadaBalanceamento de carga DNS. Ou você pode implementarFailover de DNScomo no AWS Route53, implementando verificações de integridade em seu balanceador de carga. Feito isso, o usuário externo continuará tendo acesso aos serviços no kubernetes (do office-2 e 3)