¿Necesita un clúster de Kubernetes en dos sedes tres votantes de etcd?

Tres VM de plano de control parecen tres oportunidades de sobrevivir a una mala noche. No lo son, y la distancia entre esas dos creencias es lo que convierte un diseño ordenado de tres nodos en un clúster que deja de aceptar escrituras cuando un edificio pierde la energía. Un enlace VPN entre las sedes hace que las máquinas sean accesibles entre sí y esconde el problema en lugar de resolverlo. Los votos se cuentan por miembro de etcd, y dos de esos miembros aún pueden estar detrás de un conmutador, un SAI y un enlace ascendente.

Tres nodos de plano de control, un dominio de fallo

Ejecuta kubectl get nodes, ve tres entradas de plano de control y archiva el clúster como de alta disponibilidad. Ese recuento describe capacidad programable, no supervivencia. En kubeadm sin un etcd externo, cada nodo de plano de control también aloja un miembro, así que tres nodos realmente le dan tres votantes. Si esos votantes fallan de forma independiente es una pregunta aparte que la lista de nodos no puede responder.

Dos VM en un hipervisor, dos racks en una alimentación, dos enlaces ascendentes de un ISP: cada pareja es un solo dominio con dos nombres de host. Escriba la colocación y marque qué comparte cada votante — hipervisor, PDU, conmutador de la parte superior del rack, matriz de almacenamiento, dispositivo NAT, concentrador VPN. Después elimine cada objeto compartido sobre el papel y vuelva a contar los votos que quedan. Un clúster que pierde dos votantes por un solo host fallido ha sido un clúster de un solo votante todo el tiempo; nadie le había hecho la pregunta.

Qué puede y qué no puede sobrevivir una división en dos sedes

Con tres votantes colocados dos y uno en dos sedes, el lado mayor mantiene el quórum cuando la otra sede desaparece y el lado de un solo votante nunca lo hace. Esa asimetría es aritmética, no ajuste. Cualquier clúster de etcd basado en mayorías repartido exactamente en dos sedes independientes falla la prueba "pierde cualquiera de las sedes y sigue confirmando", porque ambos lados tendrían que tener más de la mitad de los votos al mismo tiempo.

La tabla de abajo es la forma más rápida de ver qué fallos ha comprado realmente. Lea cada fila así: si toda esta fila desaparece esta noche, ¿pueden los supervivientes seguir confirmando una escritura?

Por qué el túnel nunca añade un voto

Una VPN es transporte, no un miembro. Puede hacer accesible un votante remoto y puede convertir una partición en algo que parece un tiempo de espera lento, y eso es toda su contribución al quórum. Lo que sí añade es coste, porque cada confirmación tiene que cruzar el enlace y etcd paga ese viaje de ida y vuelta en las escrituras que tocan el registro raft. Un camino que fluctúa convierte la replicación en reintentos y elecciones.

Las particiones son donde la gente espera magia, así que sea preciso con ellas. Si el enlace cae mientras el líder antiguo se sienta en el lado de un solo votante, ese lado no puede confirmar y el líder dimite cuando expira el tiempo de espera de elección, mientras el lado de dos votantes elige un sustituto. La guía de etcd sobre modos de fallo describe el comportamiento sin rodeos: servicio continuado en el lado de la mayoría, ningún segundo clúster escribible en el lado aislado.

Decida qué interrupción compra

Dos más uno es un diseño legítimo cuando la sede A es la primaria y acepta que perderla significa perder escrituras del plano de control hasta que alguien actúe. Lo que lo convierte en un defecto es dejar esa decisión implícita. Póngala en el runbook: de qué sede sobrevive su plano de control y qué hace un operador cuando la otra sede se apaga a las 03:00.

Si el requisito es en cambio "cualquiera de las sedes puede fallar", la colocación debe tener mayoría en cada sede, y tres votantes en dos sedes no pueden hacerlo. O añade un tercer dominio genuinamente independiente — una región pequeña en otro proveedor funciona si el camino hacia ella es estable — o se divide en dos clústeres con etcd separados y acepta el coste operativo de esa división. Ningún atajo de testigo lo evita: etcd no tiene un miembro árbitro ligero, así que un tercer votante es un miembro completo con sus propias exigencias de disco, memoria y red. Dibujar una caja etiquetada como testigo en el diagrama no crea uno.

El quórum no es lo mismo que el servicio

El quórum de etcd mantiene al servidor de API capaz de aceptar escrituras, y eso es todo lo que mantiene. Las comprobaciones de salud del balanceador de carga, el ingress, la alcanzabilidad de CNI a través del túnel, las zonas de conexión de volúmenes y la replicación de aplicaciones necesitan cada una su propia respuesta. Un clúster puede mantener una mayoría limpia y aun así no ofrecer nada útil a los usuarios.

Luego confirme la pertenencia que cree tener, porque los diagramas se desvían:

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

Compare la lista de miembros con el dibujo de colocación. Si dos miembros se resuelven al mismo host o al mismo rack, el dibujo es el equivocado y no el clúster, y redimensionar alrededor de una topología equivocada solo compra una versión más cara de la misma interrupción.

Antes de aprobar cualquier diseño de tres votantes, responda cuatro preguntas: cuántos votantes pierden la energía juntos, qué pérdida de sede aún deja mayoría, dónde se sienta el líder cuando el túnel cae, y qué puede hacer todavía la sede superviviente. Un "no estoy seguro" en cualquiera de ellas significa que el clúster aún no es de alta disponibilidad. Son tres máquinas que han tenido suerte.