Un cluster Kubernetes su due sedi ha bisogno di tre votanti etcd?

Tre VM del piano di controllo sembrano tre occasioni di sopravvivere a una brutta notte. Non lo sono, e la distanza tra queste due convinzioni è ciò che trasforma un ordinato progetto a tre nodi in un cluster che smette di accettare scritture quando un edificio perde l'alimentazione. Un collegamento VPN tra le sedi rende le macchine raggiungibili l'una dall'altra e nasconde il problema invece di risolverlo. I voti si contano per membro etcd, e due di quei membri possono ancora stare dietro un solo switch, un solo UPS e un solo uplink.

Tre nodi del piano di controllo, un solo dominio di guasto

Esegui kubectl get nodes, vedi tre voci del piano di controllo e archivi il cluster come ad alta disponibilità. Quel numero descrive capacità pianificabile, non sopravvivenza. In kubeadm senza un etcd esterno, ogni nodo del piano di controllo ospita anche un membro, quindi tre nodi ti danno davvero tre votanti. Se questi votanti falliscano in modo indipendente è una domanda separata a cui l'elenco dei nodi non può rispondere.

Due VM su un solo hypervisor, due rack su una sola alimentazione, due uplink da un solo ISP: ogni coppia è un unico dominio che indossa due nomi host. Scrivi il posizionamento e segna ciò che ogni votante condivide — hypervisor, PDU, switch di cima rack, array di storage, dispositivo NAT, concentratore VPN. Poi rimuovi ogni oggetto condiviso sulla carta e riconta i voti rimasti. Un cluster che perde due votanti per un solo host guasto è stato un cluster a un solo votante per tutto il tempo; nessuno gli aveva ancora fatto la domanda.

Cosa può e cosa non può sopravvivere una divisione in due sedi

Con tre votanti posizionati due e uno su due sedi, il lato più grande mantiene il quorum quando l'altra sede scompare e il lato a un solo votante mai. Quell'asimmetria è aritmetica, non messa a punto. Qualsiasi cluster etcd basato sulla maggioranza distribuito esattamente su due sedi indipendenti fallisce il test "perdi una delle due sedi e continua a confermare", perché entrambi i lati dovrebbero tenere più della metà dei voti nello stesso momento.

La tabella sotto è il modo più rapido per vedere quali guasti hai davvero comprato. Leggi ogni riga così: se tutta questa riga scompare stanotte, i sopravvissuti possono ancora confermare una scrittura?

Perché il tunnel non aggiunge mai un voto

Una VPN è trasporto, non un membro. Può rendere raggiungibile un votante remoto e può trasformare una partizione in qualcosa che sembra un timeout lento, e questo è tutto il suo contributo al quorum. Ciò che aggiunge è costo, perché ogni conferma deve attraversare il collegamento e etcd paga quel viaggio di andata e ritorno sulle scritture che toccano il log raft. Un percorso che sfarfalla trasforma la replica in nuovi tentativi ed elezioni.

Le partizioni sono il luogo dove la gente si aspetta magia, quindi sii preciso al riguardo. Se il collegamento cade mentre il vecchio leader siede dal lato a un solo votante, quel lato non può confermare e il leader si dimette quando scade il timeout di elezione, mentre il lato a due votanti elegge un sostituto. La guida di etcd ai modi di guasto descrive il comportamento senza giri di parole: servizio continuato dal lato della maggioranza, nessun secondo cluster scrivibile dal lato isolato.

Decidi quale interruzione compri

Due più uno è un progetto legittimo quando la sede A è quella primaria e accetti che perderla significhi perdere le scritture del piano di controllo finché qualcuno non agisce. Ciò che lo rende un difetto è lasciare quella decisione implicita. Mettila nel runbook: da quale sede sopravvive il tuo piano di controllo e cosa fa un operatore quando l'altra sede si spegne alle 03:00.

Se il requisito è invece "una qualsiasi delle sedi può guastarsi", il posizionamento deve tenere una maggioranza in ciascuna sede, e tre votanti su due sedi non possono farlo. O aggiungi un terzo dominio davvero indipendente — una piccola regione presso un altro provider funziona se il percorso verso di essa è stabile — oppure ti dividi in due cluster con etcd separati e accetti il costo operativo di quella divisione. Nessuna scorciatoia con un testimone lo evita: etcd non ha un membro arbitro leggero, quindi un terzo votante è un membro completo con le proprie esigenze di disco, memoria e rete. Disegnare una casella etichettata testimone sullo schema non ne crea uno.

Il quorum non è la stessa cosa del servizio

Il quorum di etcd tiene il server API in grado di accettare scritture, e questo è tutto ciò che tiene. I controlli di salute del bilanciatore di carico, l'ingress, la raggiungibilità del CNI attraverso il tunnel, le zone di collegamento dei volumi e la replica delle applicazioni hanno ciascuno bisogno della propria risposta. Un cluster può tenere una maggioranza pulita e comunque non offrire nulla di utile agli utenti.

Poi conferma l'appartenenza che credi di avere, perché gli schemi derivano:

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

Confronta l'elenco dei membri con il disegno del posizionamento. Se due membri si risolvono allo stesso host o allo stesso rack, è il disegno a essere sbagliato e non il cluster, e ridimensionare attorno a una topologia errata compra solo una versione più costosa della stessa interruzione.

Prima di approvare qualsiasi progetto a tre votanti, rispondi a quattro domande: quanti votanti perdono l'alimentazione insieme, quale perdita di sede lascia ancora una maggioranza, dove siede il leader quando il tunnel cade, e cosa può ancora fare la sede sopravvissuta. Un "non sono sicuro" su una di esse significa che il cluster non è ancora ad alta disponibilità. Sono tre macchine che sono state fortunate.