Precisa un clúster de Kubernetes en dúas sedes tres votantes de etcd?

Tres VM de plano de control parecen tres oportunidades de sobrevivir a unha mala noite. Non o son, e a distancia entre esas dúas crenzas é o que converte un deseño ordenado de tres nodos nun clúster que deixa de aceptar escrituras cando un edificio perde a enerxía. Unha ligazón VPN entre as sedes fai que as máquinas sexan accesibles entre si e esconde o problema en lugar de resolvelo. Os votos cóntanse por membro de etcd, e dous deses membros aínda poden estar detrás dun conmutador, un SAI e unha ligazón ascendente.

Tres nodos de plano de control, un dominio de fallo

Executas kubectl get nodes, ves tres entradas de plano de control e arquivas o clúster como de alta dispoñibilidade. Ese reconto describe capacidade planificable, non supervivencia. En kubeadm sen un etcd externo, cada nodo de plano de control tamén aloxa un membro, así que tres nodos realmente che dan tres votantes. Se eses votantes fallan de forma independente é unha pregunta aparte que a lista de nodos non pode responder.

Dúas VM nun hipervisor, dous racks nunha alimentación, dúas ligazóns ascendentes dun ISP: cada parella é un só dominio con dous nomes de host. Escribe a colocación e marca que comparte cada votante — hipervisor, PDU, conmutador da parte superior do rack, matriz de almacenamento, dispositivo NAT, concentrador VPN. Despois elimina cada obxecto compartido sobre o papel e volve contar os votos que quedan. Un clúster que perde dous votantes por un só host fallido foi un clúster dun só votante todo o tempo; ninguén lle fixera a pregunta.

Que pode e que non pode sobrevivir unha división en dúas sedes

Con tres votantes colocados dous e un en dúas sedes, o lado maior mantén o quórum cando a outra sede desaparece e o lado dun só votante nunca o fai. Esa asimetría é aritmética, non axuste. Calquera clúster de etcd baseado en maiorías repartido exactamente en dúas sedes independentes falla a proba "perde calquera das sedes e segue confirmando", porque ambos os lados terían que ter máis da metade dos votos ao mesmo tempo.

A táboa de abaixo é a forma máis rápida de ver que fallos compraches realmente. Le cada fila así: se toda esta fila desaparece esta noite, poden os superviventes seguir confirmando unha escritura?

Por que o túnel nunca engade un voto

Unha VPN é transporte, non un membro. Pode facer accesible un votante remoto e pode converter unha partición en algo que parece un tempo de espera lento, e iso é toda a súa contribución ao quórum. O que si engade é custo, porque cada confirmación ten que cruzar a ligazón e etcd paga esa viaxe de ida e volta nas escrituras que tocan o rexistro raft. Un camiño que fluctúa converte a replicación en reintentos e eleccións.

As particións son onde a xente espera maxia, así que sexa preciso con elas. Se a ligazón cae mentres o líder antigo senta no lado dun só votante, ese lado non pode confirmar e o líder dimite cando expira o tempo de espera de elección, mentres o lado de dous votantes elixe un substituto. A guía de etcd sobre modos de fallo describe o comportamento sen rodeos: servizo continuado no lado da maioría, ningún segundo clúster escribible no lado illado.

Decide que interrupción compras

Dous máis un é un deseño lexítimo cando a sede A é a primaria e aceptas que perdela significa perder escrituras do plano de control ata que alguén actúe. O que o converte nun defecto é deixar esa decisión implícita. Pon a no runbook: de que sede sobrevive o teu plano de control e que fai un operador cando a outra sede se apaga ás 03:00.

Se o requisito é en cambio "calquera das sedes pode fallar", a colocación debe ter maioría en cada sede, e tres votantes en dúas sedes non poden facelo. Ou engades un terceiro dominio xenuinamente independente — unha rexión pequena noutro provedor funciona se o camiño cara a ela é estable — ou divídeste en dous clústers con etcd separados e aceptas o custo operativo desa división. Ningún atallo de testemuña o evita: etcd non ten un membro árbitro lixeiro, así que un terceiro votante é un membro completo coas súas propias esixencias de disco, memoria e rede. Debuxar unha caixa etiquetada como testemuña no diagrama non crea unha.

O quórum non é o mesmo que o servizo

O quórum de etcd mantén o servidor de API capaz de aceptar escrituras, e iso é todo o que mantén. As comprobacións de saúde do balanceador de carga, o ingress, a alcanzabilidade de CNI a través do túnel, as zonas de conexión de volumes e a replicación de aplicacións necesitan cada unha a súa propia resposta. Un clúster pode manter unha maioría limpa e aínda así non ofrecer nada útil aos usuarios.

Logo confirma a pertenza que cres ter, porque os diagramas desvíanse:

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

Compara a lista de membros co debuxo de colocación. Se dous membros se resolven no mesmo host ou no mesmo rack, o debuxo é o equivocado e non o clúster, e redimensionar arredor dunha topoloxía equivocada só compra unha versión máis cara da mesma interrupción.

Antes de aprobar calquera deseño de tres votantes, responde catro preguntas: cantos votantes perden a enerxía xuntos, que perda de sede aínda deixa maioría, onde senta o líder cando o túnel cae, e que pode facer aínda a sede supervivente. Un "non estou seguro" en calquera delas significa que o clúster aínda non é de alta dispoñibilidade. Son tres máquinas que tiveron sorte.