Ogni volta che un cliente mi chiede “voglio il database in alta disponibilità dentro Kubernetes”, so già che la conversazione finirà con me a spiegare perché MariaDB Galera su RKE2 non è la scelta che immaginano. Non perché Galera sia una cattiva tecnologia — è un ottimo motore di replica multi-master sincrona — ma perché il matrimonio tra un cluster a quorum stateful e un orchestratore progettato per trattare i pod come bestiame sacrificabile genera più notti insonni che uptime.
Split-brain, quorum e il bootstrap manuale delle 3 di notte
Il problema strutturale è chiaro a chiunque abbia gestito Galera sul serio: il cluster ragiona per quorum e Group Communication System (GCS), Kubernetes ragiona per riconciliazione dello stato desiderato. I due modelli non parlano la stessa lingua nei momenti critici.
Il caso tipico che mi è capitato più volte: un drain di un nodo RKE2 per manutenzione, oppure un’eviction dovuta a memory pressure, che fa cadere un pod Galera mentre gli altri due sono sotto carico di scrittura. Se l’eviction non è ordinata — e con StatefulSet e PodDisruptionBudget mal configurati capita — ti ritrovi due nodi che perdono contatto e un GCS che non riesce a stabilire chi ha lo stato più recente. Risultato: cluster in stato Non-Primary, scritture bloccate, applicazioni in errore.
La difesa che adotto è sempre la stessa combinazione:
- PodDisruptionBudget con minAvailable: 2 su un cluster a tre nodi, non negoziabile;
- anti-affinity rigida per non avere mai due membri Galera sullo stesso nodo fisico;
- terminationGracePeriodSeconds generoso per lasciare completare l’
IST/SST; - e soprattutto disabilitazione del bootstrap automatico, perché un chart che decide da solo chi è il “primo componente” quando tutti i pod ripartono insieme è la ricetta perfetta per perdere dati.
Nonostante tutto questo, il bootstrap manuale forzato — recuperare il grastate.dat, individuare il nodo con il seqno più alto, settare safe_to_bootstrap: 1 e ripartire da lì — è un rituale che ho dovuto eseguire in piena notte più volte di quante ne voglia ammettere. E il punto è proprio questo: un’infrastruttura HA che richiede intervento umano manuale per riprendersi non è veramente HA, è una promessa con asterisco.
Lo storage persistente: dove Galera soffre davvero
Qui la scelta dello storage backend cambia tutto, e le esperienze sono state istruttive.
Con Longhorn ho ottenuto la portabilità e il failover dei volumi che rendono felice l’anima “cloud native”, ma al prezzo di una latenza di rete aggiuntiva sulla replica del blocco che si somma alla replica sincrona di Galera. In pratica paghi due volte: Galera replica in sincrono a livello applicativo, Longhorn replica in sincrono a livello di blocco. Sotto carico di scrittura reale questo ha fatto esplodere i write conflict e i deadlock certification-based tipici di Galera, con rollback delle transazioni che l’applicazione non era pronta a gestire.
La configurazione che alla fine performa meglio è quasi controintuitiva: local-path / local PV su NVMe, delegando l’intera responsabilità della ridondanza a Galera stesso. Ha senso — Galera già mantiene tre copie dei dati, replicarle di nuovo a livello storage è ridondanza sprecata che aggiunge solo latenza. Il rovescio della medaglia è che perdi la portabilità del pod: se muore il nodo, quel membro deve rifare un SST completo da zero, che su dataset grandi significa minuti (o decine di minuti) di ricostruzione con impatto sulle prestazioni degli altri nodi.
Lo storage esterno via CSI dedicato è la via di mezzo, ma introduce dipendenze da SAN/NAS che spesso vanificano il senso stesso di essere dentro Kubernetes.
Cosa consiglio davvero ai clienti
Quando un cliente mi chiede HA sul database, il mio approccio è diventato pragmatico. Sconsiglio Galera su RKE2 gestito a mano tramite Helm chart generici in praticamente tutti gli scenari di produzione seria. Le alternative che propongo, in ordine di preferenza secondo il contesto:
- Un operator dedicato — MariaDB Operator o Percona XtraDB Cluster Operator — quando il database deve stare dentro il cluster per ragioni di FinOps o di coerenza operativa. L’operator è la differenza tra un cluster che si auto-ripara e uno che ti sveglia. Codifica la conoscenza operativa del recovery, del backup, del rolling upgrade e del bootstrap sicuro. È la mia raccomandazione principale: più flessibile e più affidabile della gestione artigianale.
- Un database gestito o su VM classiche fuori da Kubernetes quando il carico transazionale è pesante e la latenza conta. Un cluster Galera su tre VM ben tunate, o un servizio DB gestito da provider cloud sovrano, offre spesso un rapporto affidabilità/complessità nettamente migliore, mantenendo il dato dove i modelli di consistency sono progettati per viverci.
La domanda vera non è “posso mettere Galera su RKE2?” — sì, puoi. È “chi si sveglia alle 3 di notte quando il quorum si rompe, e vuoi davvero che sia una persona invece di un operator?”.
Il verdetto
Il mio voto è 0: non conviene muoversi verso MariaDB Galera gestito manualmente su RKE2 come pattern di alta disponibilità in produzione. La complessità operativa è reale, il recovery non è deterministico senza automazione, e lo stacking di replica sincrona su storage sincrono è un anti-pattern prestazionale. Se il database deve stare dentro Kubernetes, si passa da un operator dedicato, che trasforma un incubo notturno in un flusso riconciliato. Se non c’è un motivo forte per l’in-cluster, il database sta meglio fuori. Galera resta valido; è il modo in cui la maggior parte lo installa su Kubernetes a essere sbagliato.