Ao tentar configurar um cluster experimental do Kubernetes (em algumas VMs no meu laptop) como "alta disponibilidade", encontrei o conselho para 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 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 master do que nos backups. Portanto, 101 e 100, respectivamente, serão suficientes.
e essas configurações me surpreendem. Aparentemente eu tenho que escolher qual desses sistemas será o mestre inicial e tenho que configurar isso "duramente" 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 possuem uma configuração semelhante (um líder ativo e vários líderes em espera) e todos são configurados "identicamente" (a escolha é 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?
Responder1
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ê precisará inicializar um serviço com algo de nível inferior para iniciar tudo.
manter vivoconforme configurado novinculado kubernetes doccofornece um únicoVRRPendereço IP virtual como endpoint altamente disponível compartilhado entre os mestres.
Todos os nós configuram o mesmo endereço IP VRRP (ou nome) e o keepalived move esse endereço entre os mestres. A "eleição" é concluída na verificação de integridade e na lógica de failover.
Uma alternativa a esse método é transferir 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.
Responder2
Sei que este é um tópico obsoleto, mas pensei em intervir 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 saúde que aumentará a prioridade (por exemplo, há quanto tempo o KeepaliveD está em execução ou uma verificação de saúde para o serviço local para o qual você deseja HA...)
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, então o "IP mais alto" vence.
Isso pode causar um atraso inicial se todos os nós iniciarem ao mesmo tempo, mas isso tem sido aceitável onde usamos isso.
Espero que ajude.