Kubernetes K3s ad alta disponibilità: replica sincrona e failover a 2 nodi

Semplificare l’alta disponibilità di K3s: perché scegliere SafeKit invece di MetalLB e Longhorn?

Mentre lo stack open-source standard (MetalLB + Longhorn) per K3s è potente per i grandi data center, introduce una complessità eccessiva per i siti on-premise a 2 nodi. SafeKit semplifica l’ambiente K3s sostituendo gli strumenti di rete e di archiviazione standalone con un unico motore HA consolidato.

Perché usare SafeKit per l’alta disponibilità (HA) di K3s a 2 nodi?

• Vera alta disponibilità a 2 nodi: SafeKit fornisce una ridondanza completa con soli 2 nodi, eliminando il requisito di 3 nodi per il quorum etcd.
• Perdita di dati pari a zero (RPO = 0): sostituisce l’archiviazione a blocchi ad alto sovraccarico con la replica sincrona a livello di byte per prestazioni SSD locali.
• Protezione flessibile a livello di file: SafeKit esegue la replica basata sull’host a livello di file, il che è completamente trasparente per l’applicazione. Protegge non solo i database, ma anche tutte le cartelle e i dati associati. È possibile replicare le cartelle esistenti esattamente dove sono installate, anche sul disco di sistema.
• IP virtuale (VIP) integrato: gestisce nativamente l’IP del cluster a livello di kernel, eliminando la necessità di configurazioni MetalLB separate.
• Failover e failback automatici: attiva una transizione immediata al nodo secondario in caso di errore; una volta che il nodo primario è integro, SafeKit esegue la risincronizzazione automatica dei dati senza intervento manuale.
• Overhead ultra-basso: SafeKit funziona senza il pesante overhead di gestione dei pod di archiviazione (CSI/Longhorn) e dei pod di rete (CNI/MetalLB) richiesti dagli stack standard, liberando RAM e CPU critiche per le tue applicazioni.
• Adatto ai generalisti IT: sostituisce la complessa infrastruttura YAML per il networking e lo storage con una semplice GUI web e script di distribuzione automatizzati, lasciandoti concentrare solo sulle tue applicazioni.

Alta disponibilità (HA) senza condivisione per cluster K3s a 2 nodi

⚡ Guida rapida all’installazione di un cluster Kubernetes HA >

Indice

• Come implementa il software SafeKit un cluster Kubernetes K3s ad alta disponibilità?
• Come funziona il cluster mirror SafeKit con Kubernetes K3S?
• Limitazioni SafeKit High Availability
• Confronto: SafeKit vs. stack K3s standard (MetalLB e Longhorn)
• Guida video: configurazione di un cluster HA mirror SafeKit
• 🔍 Esplora SafeKit

Come implementa il software SafeKit un cluster Kubernetes K3s ad alta disponibilità?

Come si implementa l’alta disponibilità per un cluster Kubernetes K3s a 2 nodi?

È possibile implementare l’alta disponibilità (HA) per un cluster Kubernetes K3s a 2 nodi utilizzando il modulo mirror SafeKit k3s.safe. Questa soluzione consente di implementare un ambiente ridondante senza la necessità di storage NFS esterno, di un database di configurazione esterno dedicato o di competenze specialistiche Kubernetes.

Perché usare K3s per l’edge computing e l’IoT?

K3s è il motore Kubernetes preferito per l’IoT e l’edge computing perché è una distribuzione certificata e leggera, progettata per ambienti con risorse limitate. Semplifica il sovraccarico operativo di Kubernetes standard, mantenendo al contempo la piena compatibilità.

Quali sono le caratteristiche principali del modulo mirror k3s.safe?

Il modulo k3s.safe fornisce uno stack HA completo per K3s implementando:

• Nodi attivi doppi: esegue contemporaneamente 2 master/agenti K3s attivi per ospitare i pod.
• Replicazione del database: replicazione in tempo reale del database di configurazione di MariaDB tra i nodi.
• Archiviazione persistente: replica dei volumi persistenti tramite un client NFS integrato con provisioning dinamico (nfs-client).
• Continuità della rete: include un indirizzo IP virtuale per un accesso client senza interruzioni.
• Recupero automatico: supporto completo per il failover e il failback automatici.

Oltre a K3s, quali applicazioni e ambienti può proteggere SafeKit?

SafeKit è una soluzione versatile ad alta disponibilità per Windows e Linux che va ben oltre cluster mirror K3s. Consente la replica sincrona in tempo reale e il failover automatico per un’ampia gamma di carichi di lavoro critici, tra cui:

• Ambienti virtuali e fisici: macchine virtuali Hyper-V o KVM complete.
• Orchestrazione di container: ambienti Docker, Podman.
• Dati e servizi: directory di file individuali, servizi e vari database.
• Infrastruttura cloud: alta disponibilità per le applicazioni cloud.

SafeKit fornisce inoltre ai cluster farm il bilanciamento del carico di rete nativo e il failover per le applicazioni senza stato come i server Web.

💡 Esplora l’elenco completo delle soluzioni HA supportate qui.

In che modo SafeKit garantisce l’alta disponibilità di K3s?

Architettura e logica di ridondanza per un cluster K3s a 2 nodi tramite SafeKit

Meccanismo di failover automatico: in caso di errore del nodo primario, SafeKit migra automaticamente gli IP virtuali e i servizi di archiviazione al nodo secondario, garantendo un servizio ininterrotto per il cluster K3s.

Come funziona il cluster mirror SafeKit con Kubernetes K3S?

Passaggio 1: replica di file a livello di byte in un cluster mirror

Questa fase illustra l’architettura ad alta disponibilità tra il server 1 (PRIM) e il server 2 (SECOND). Entrambi i server eseguono i componenti master e agent di K3s come definito nella tabella dell’architettura.

Attualmente, l’IP virtuale (VIP), l’archiviazione persistente NFS e MariaDB sono attivi solo sul server 1 (PRIM). I componenti master K3s su entrambi i nodi si sincronizzano tra loro accedendo allo stato del cluster tramite l’IP virtuale e la porta MariaDB. SafeKit implementa la replica sincrona di MariaDB e dei file NFS persistenti, garantendo zero perdita di dati (RPO = 0) in caso di guasto.

I master K3s distribuiscono il carico di lavoro su entrambi i nodi (o più) comunicando direttamente con gli agenti K3s. I client esterni si connettono al
indirizzo IP virtuale del cluster sul nodo PRIM. Utilizzando i meccanismi standard Kubernetes, il master K3s inoltra il traffico ai pod distribuiti sui nodi. Allo stesso modo, i pod accedono ai loro volumi persistenti (PV) sul server PRIM tramite l’IP virtuale e la porta NFS.

Fase 2: Failover automatico e continuità del servizio

Quando il server 1 (PRIM) si guasta, il server 2 (SECOND) assume automaticamente le operazioni del cluster per garantirne la continuità.

SafeKit rileva l’errore e migra immediatamente l’indirizzo IP virtuale del cluster al Server 2. Quindi, promuove i servizi locali MariaDB e NFS a uno stato attivo. Grazie alla replica sincrona eseguita nel Passaggio 1, tutti i database MariaDB e i file NFS Persistent Volume (PV) sono già aggiornati sul Server 2, garantendo l’assenza di perdita di dati.

Con lo stato del cluster conservato, il master K3s sul server 2 continua l’esecuzione. Rileva la perdita dell’agente del server 1 e ripianifica automaticamente i pod interessati sui restanti agenti K3s attivi. Il tempo totale di failover (RTO) è la somma dell’intervallo di rilevamento dei guasti (impostazione predefinita: 30 secondi) e del tempo necessario ai componenti K3s per inizializzarsi sul nodo secondario.

Mentre il server 1 è offline, i servizi MariaDB e NFS continuano a essere in esecuzione sul server 2, scrivendo le modifiche solo in locale.

Fase 3: Failback e reintegrazione automatica

Il failback si verifica quando il Server 1 viene riavviato dopo che il problema iniziale è stato risolto. SafeKit risincronizza automaticamente i file MariaDB e NFS, aggiornando solo i dati modificati sul Server 2 durante il tempo di inattività. Questo processo di reintegrazione non è dirompente ; i componenti master e agent di K3s continuano a essere in esecuzione sul Server 2 senza interruzioni.

SafeKit ottimizza il tempo di ripristino in base al modo in cui il server è stato arrestato:

• Arresto pulito: se SafeKit è stato arrestato intenzionalmente sul server 1, solo le zone specifiche modificate all’interno dei file vengono risincronizzate utilizzando le bitmap di rilevamento delle modifiche. Ciò garantisce una reintegrazione ultraveloce.
• Arresto anomalo del sistema (ad es. interruzione di corrente): se il server 1 ha subito uno spegnimento anomalo, le bitmap di modifica vengono ignorate per motivi di sicurezza. SafeKit risincronizza invece tutti i file con un timestamp di modifica più recente dell’ultimo punto di sincronizzazione stabilito, garantendo la totale integrità dei dati.

Fase 4: ripristino dell’alta disponibilità e della distribuzione del carico

Dopo la reintegrazione, il cluster torna alla modalità mirror completa, rispecchiando lo stato descritto nel passaggio 1. Il sistema è nuovamente in uno stato di alta disponibilità: i servizi MariaDB e NFS rimangono attivi sul server 2, mentre SafeKit esegue la replica in tempo reale di tutti gli aggiornamenti dei file sul server 1.

Il master K3s e l’agente K3s vengono riavviati automaticamente sul server 1. Lo scheduler Kubernetes ora riconosce il server 1 come un nodo integro e può iniziare a riprogrammare i pod per distribuire il carico di lavoro su entrambi i server.

Se l’amministratore preferisce che i servizi MariaDB e NFS vengano eseguiti sul Server 1 (ripristinando il ruolo PRIM originale), è possibile attivare manualmente un failover tramite la console web in un momento opportuno o automatizzarlo tramite le impostazioni di configurazione.

Come configurare un cluster mirror SafeKit?

La console web SafeKit offre un’interfaccia intuitiva per orchestrare l’alta disponibilità delle applicazioni critiche. In pochi passaggi, è possibile configurare un cluster mirror SafeKit per garantire la continuità aziendale:

• Failover dell’applicazione (scheda Macro): definire i servizi dell’applicazione specifici da riavviare automaticamente in caso di errore.
• Rete/i heartbeat: percorso/i di comunicazione dedicato/i utilizzato/i dai nodi del cluster per monitorare continuamente lo stato di salute e la disponibilità reciproca e per sincronizzare le decisioni di failover.
• Gestione IP virtuale: configurare l’IP virtuale (VIP) per la riconnessione trasparente del client dopo un failover.
• Replicazione in tempo reale: selezionare le directory critiche per la replicazione sincrona a livello di byte basata sull’host.
• Checkers: monitora lo stato di salute dell’applicazione e avvia il ripristino automatico in caso di rilevamento di un errore di processo.

Il cluster SafeKit include un verificatore di split-brain dedicato per risolvere i problemi di isolamento della rete senza la necessità di una terza macchina witness o di una rete heartbeat aggiuntiva. Per saperne di più su heartbeat, failover e quorum in un cluster.

Come monitorare un cluster mirror SafeKit?

La console di gestione SafeKit offre una visione unificata della tua infrastruttura ad alta disponibilità. Consente agli amministratori di monitorare lo stato operativo del cluster e di tracciare la sincronizzazione dei dati in tempo reale.

Per un cluster mirror a 2 nodi, la console visualizza chiaramente i ruoli di ciascun server:

• PRIM (primario): il nodo attivo che attualmente esegue l’applicazione e gestisce l’IP virtuale. Esegue scritture sull’archiviazione locale e la replica in tempo reale sul nodo secondario.
• SECOND: il nodo di standby riceve aggiornamenti sincroni a livello di byte. È pronto a subentrare immediatamente in caso di errore del nodo primario.
• Stato ALONE: avvisa visivamente quando il cluster è in esecuzione su un singolo nodo (ad esempio, durante la manutenzione o dopo un errore), indicando che la ridondanza è temporaneamente persa.
• Avanzamento della risincronizzazione: quando un nodo guasto si riprende, il suo stato diventa arancione durante la reintegrazione dei dati in background, garantendo l’assenza di tempi di inattività durante la fase di “ritorno alla normalità”.

Oltre alle semplici icone di stato, l’interfaccia fornisce un’orchestrazione di failover con un solo clic, consentendo di riassegnare manualmente il ruolo primario per la manutenzione pianificata, garantendo al contempo la disponibilità continua per l’attività dell’utente.

Limitazioni SafeKit High Availability

Confronto: SafeKit vs. stack K3s standard (MetalLB e Longhorn)

Confronto: SafeKit vs. soluzioni open source standard (MetalLB + Longhorn)

In sintesi, mentre uno stack fai-da-te standard (MetalLB + Longhorn) offre modularità per gli esperti Kubernetes, crea una dipendenza circolare in cui gli strumenti di archiviazione e di rete sono vulnerabili agli stessi errori dei nodi che sono progettati per gestire. SafeKit interrompe questo ciclo operando come uno strato di infrastruttura indipendente; fornisce una soluzione HA a 2 nodi più robusta e indipendente dall’hardware che rimane operativa anche se il motore Kubernetes o il sistema operativo host si blocca. Ciò garantisce il ripristino automatico e l’integrità dei dati senza il pesante sovraccarico di risorse, il quorum obbligatorio a tre nodi o la complessità di configurazione richiesta dai tradizionali sistemi di archiviazione a blocchi distribuiti e dagli overlay di rete.

Guida video: configurazione di un cluster mirror SafeKit HA

Video SafeKit: clustering a livello di applicazione (8:47)

Questo video illustra l’alta disponibilità di SafeKit per Microsoft SQL Server e fornisce un’eccellente panoramica di come la soluzione protegga gli ambienti K3s. SafeKit funziona in modo identico per qualsiasi altro database o applicazione business-critical.

Momenti salienti del video

1. 🎬 2 nodi con SQL Server (0:32)
2. 🎬 Configurare il cluster e il modulo mirror.safe (3:58)
3. 🎬 Avviare e testare la replica, la migrazione e il failover di SQL in caso di arresto anomalo (4:17)

<br />

🔍 Esplora SafeKit

Trova informazioni sulle funzionalità, le architetture, i video, la documentazione e la versione di prova gratuita di SafeKit.