Um cluster Kubernetes em dois sites precisa de três votantes etcd?

Três VMs de plano de controle parecem três chances de sobreviver a uma noite ruim. Não são, e a distância entre essas duas crenças é o que transforma um desenho arrumado de três nós num cluster que deixa de aceitar escritas quando um prédio perde a energia. Um link VPN entre os sites torna as máquinas alcançáveis umas pelas outras e esconde o problema em vez de resolvê-lo. Os votos são contados por membro do etcd, e dois desses membros ainda podem ficar atrás de um único switch, um único UPS e um único uplink.

Três nós de plano de controle, um domínio de falha

Você executa kubectl get nodes, vê três entradas de plano de controle e registra o cluster como de alta disponibilidade. Esse número descreve capacidade agendável, não sobrevivência. No kubeadm sem etcd externo, cada nó de plano de controle também hospeda um membro, então três nós realmente dão três votantes. Se esses votantes falham de forma independente é uma pergunta separada que a lista de nós não pode responder.

Duas VMs num hipervisor, dois racks numa alimentação, dois uplinks de um ISP: cada par é um único domínio usando dois nomes de host. Escreva a colocação e marque o que cada votante compartilha — hipervisor, PDU, switch do topo do rack, array de armazenamento, dispositivo NAT, concentrador VPN. Depois remova cada objeto compartilhado no papel e reconte os votos restantes. Um cluster que perde dois votantes por um único host falho sempre foi um cluster de um único votante; ninguém tinha feito essa pergunta a ele.

O que uma divisão em dois sites pode e não pode sobreviver

Quando três votantes são colocados dois e um em dois sites, o lado maior mantém o quórum quando o outro site desaparece, e o lado de um votante nunca. Essa assimetria é aritmética, não ajuste. Qualquer cluster etcd baseado em maioria distribuído exatamente por dois sites independentes falha no teste "perca qualquer um dos sites e continue confirmando", porque os dois lados teriam de deter mais da metade dos votos ao mesmo tempo.

A tabela abaixo é a forma mais rápida de ver quais falhas você realmente comprou. Leia cada linha assim: se a linha inteira desaparecer esta noite, os sobreviventes ainda podem confirmar uma escrita?

Por que o túnel nunca adiciona um voto

Uma VPN é transporte, não um membro. Pode tornar um votante remoto alcançável e pode transformar uma partição em algo que parece um timeout lento, e essa é toda a sua contribuição para o quórum. O que ela adiciona é custo, porque cada confirmação precisa atravessar o link e o etcd paga essa ida e volta nas escritas que tocam o log raft. Um caminho que oscila transforma a replicação em novas tentativas e eleições.

Partições são onde as pessoas esperam magia, então seja preciso sobre elas. Se o link cai enquanto o líder antigo está do lado de um votante, esse lado não pode confirmar e o líder se retira quando o tempo limite de eleição expira, enquanto o lado de dois votantes elege um substituto. O guia do etcd sobre modos de falha descreve o comportamento sem rodeios: serviço contínuo do lado da maioria, nenhum segundo cluster gravável do lado isolado.

Decida qual interrupção você compra

Dois mais um é um desenho legítimo quando o Site A é o primário e você aceita que perdê-lo significa perder escritas do plano de controle até alguém agir. O que o torna um defeito é deixar essa decisão implícita. Coloque no runbook: de qual site seu plano de controle sobrevive e o que um operador faz quando o outro site cai às 03:00.

Se o requisito for "qualquer um dos sites pode falhar", a colocação deve ter maioria em cada site, e três votantes em dois sites não conseguem isso. Ou você adiciona um terceiro domínio genuinamente independente — uma região pequena em outro provedor funciona se o caminho até ela for estável — ou se divide em dois clusters com etcd separado e aceita o custo operacional dessa divisão. Nenhum atalho de testemunha evita isso: o etcd não tem membro árbitro leve, então um terceiro votante é um membro completo com suas próprias exigências de disco, memória e rede. Desenhar uma caixa rotulada como testemunha no diagrama não cria uma.

Quórum não é a mesma coisa que serviço

O quórum do etcd mantém o servidor de API capaz de aceitar escritas, e é tudo o que ele mantém. As verificações de saúde do balanceador de carga, o ingress, a alcançabilidade do CNI pelo túnel, as zonas de conexão de volumes e a replicação de aplicações precisam cada uma da sua própria resposta. Um cluster pode ter uma maioria limpa e ainda assim não oferecer nada útil aos usuários.

Depois confirme a associação que você acha que tem, porque os diagramas derivam:

kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table

Compare a lista de membros com o desenho de colocação. Se dois membros resolvem para o mesmo host ou o mesmo rack, o desenho é o errado e não o cluster, e redimensionar em torno de uma topologia equivocada compra só uma versão mais cara da mesma interrupção.

Antes de aprovar qualquer desenho de três votantes, responda a quatro perguntas: quantos votantes perdem a energia juntos, qual perda de site ainda deixa maioria, onde fica o líder quando o túnel cai, e o que o site sobrevivente ainda pode fazer. Um "não tenho certeza" em qualquer uma delas significa que o cluster ainda não é de alta disponibilidade. São três máquinas que tiveram sorte.