Ao tentar configurar um cluster experimental do Kubernetes (em algumas VMs no meu laptop) como "alta disponibilidade", encontrei o conselho de fazer isso usando a combinação de keepalived e haproxy ( https://github.com/kubernetes/kubeadm/blob /master/docs/ha-considerations.md#options-for-software-load-balancing ).
Olhando para as definições de configuração que eu li
${STATE} é MASTER para um e BACKUP para todos os outros hosts, portanto, o IP virtual será inicialmente atribuído ao MASTER.
${PRIORITY} deve ser maior no mestre do que nos backups. Portanto, 101 e 100, respectivamente, serão suficientes.
e essas configurações me surpreendem. Aparentemente, tenho que escolher qual desses sistemas será o mestre inicial e tenho que configurar isso "hard" nos próprios nós.
Para mim, essa configuração de "alta disponibilidade" se desvia da analogia "animal de estimação"/"gado" que encontro no Kubernetes.
Outros sistemas como, por exemplo, o HBase têm uma configuração semelhante (um ativo e vários líderes de espera) e todos são configurados "identicamente" (a seleção é feita via ZooKeeper).
Existe uma maneira de configurar o Keepalived (para uso no Kubernetes) de forma que todos os nós tenham a mesma configuração e ainda funcione corretamente?
O próprio Kubernetes fornece serviços de "gado" para aplicativos. Embora muitos dos serviços "mestres" do kubernetes sejam baseados na mesma infraestrutura, em algum momento você precisa inicializar um serviço com algo de nível inferior para iniciar tudo.
keepalived conforme configurado no docco do kubernetes vinculado fornece um único endereço IP virtual VRRP como o ponto de extremidade altamente disponível compartilhado entre os mestres.
Todos os nós configuram o mesmo endereço IP (ou nome) do VRRP e movem esse endereço em torno dos mestres. A "eleição" é concluída na verificação de integridade do keepalived e na lógica de failover.
Uma alternativa a esse método é mover a decisão de balanceamento de carga para um dispositivo externo ou para os clientes. Você pode executar um proxy reverso em cada nó ( como haproxy ) que pode pesar os servidores kube-api e concluir as verificações de integridade.
Percebo que este é um tópico obsoleto, mas pensei em entrar em contato de qualquer maneira, pois executei o KeepaliveD com configuração idêntica em todos os nós.
No Debian, temos todos os nós inicialmente configurados para BACKUP e temos algum tipo de verificação de integridade que aumentará a prioridade (por exemplo, há quanto tempo o KeepaliveD está em execução ou uma verificação de integridade para o serviço local para o qual você deseja HA...)
O VRRP v2, que é o que KeepaliveD (pelo menos as versões com as quais trabalhei) está rodando no Debian, tem um recurso de desempate, onde se a prioridade for a mesma em vários nós, o "IP mais alto" vence.
Isso pode causar um atraso inicial se todos os nós iniciarem ao mesmo tempo, mas isso foi aceitável onde usamos isso.
Espero que ajude.