Alta disponibilità K3S con SafeKit: installare il modulo k3s.safe per il failover

Guida rapida all’installazione ad alta disponibilità per Kubernetes

Questa guida spiega come configurare un cluster mirror per Kubernetes utilizzando SafeKit, garantendo il failover automatico e la replica sincrona senza la necessità di uno storage condiviso.

Per assistenza, puoi utilizzare SafeKit AI 🤖.

1. Panoramica

• Architettura: utilizza un sistema a due nodi (primario/secondario).
• Protezione dei dati: implementa la replica sincrona in tempo reale per una perdita di dati pari a zero (RPO = 0).

2. Installazione

• Software: installare il motore SafeKit su entrambi i server.
• Modulo: Scarica il modulo dell’applicazione k3s.safe preconfigurato.

3. Configurazione

• Console Web: configurare le cartelle specifiche contenenti i file Kubernetes.
• Monitoraggio: avvia il monitoraggio e la protezione dell’applicazione Kubernetes.

Limitazioni SafeKit High Availability

Panoramica della soluzione SafeKit/Kubernetes

La soluzione è descritta qui: 💡 Kubernetes K3s ad alta disponibilità: replica sincrona e failover a 2 nodi

Installazione e configurazione della soluzione SafeKit/Kubernetes su Linux (k3s.safe)

1. Scarica i pacchetti

• Scarica la versione gratuita di SafeKit 8.2 su Linux (safekitlinux_xx.bin)
• Scarica il modulo Linux k3s.safe
• Scarica lo script k3sconfig.sh
• Documentazione (pptx)

Nota: lo script k3sconfig.sh installa K3S, MariaDB, NFS e SafeKit su 2 nodi Linux Ubuntu 24.04.

Scarica SafeKit (Linux) >

Scarica k3s.safe (Linux) >

Scarica k3sconfig.sh >

Documentazione (pdf) >

2. Prima su entrambi i nodi

Su 2 nodi Linux Ubuntu 24.04, come root:

• Assicurati che il nodo abbia accesso a Internet (anche tramite un proxy)
• Copia k3sconfig.sh, k3s.safe e il pacchetto safekit_xx.bin in una directory e spostati al suo interno con il comando cd
• Rinomina il file .bin in “safekit.bin”
• Assicurati k3sconfig.sh e safekit.bin siano eseguibili.
• Modificare lo script k3sconfig.sh e personalizzare le variabili d’ambiente in base al proprio ambiente (incluso un IP virtuale)
• Eseguire su entrambi i nodi: ./k3sconfig.sh prereq

Lo script:

• Installare i pacchetti Debian richiesti: alien, nfs-kernel-server, nfs-common, mariadb-server
• Installazione sicura di MariaDB
• Creare directory per la replica dei file
• Preparare il server NFS per la condivisione delle directory replicate
• Installare SafeKit

3. Sul primo nodo

Eseguire sul primo nodo: ./k3sconfig.sh first

Lo script:

• Creare il database di configurazione K3S e l’utente k3s
• Creare il file del volume di archiviazione replicato (file sparso) e formattarlo come file system xfs
• Creare la configurazione del cluster safekit e applicarla
• Installare e configurare il modulo k3s.safe sul cluster
• Avviare il modulo k3s come “prim” sul primo nodo
• Scarica, installa e avvia k3s
• Scarica e installa il grafico Helm di nfs-subdir-external-provisioner
• Visualizza il token K3S (da utilizzare durante la seconda fase di installazione del nodo)

4. Sul secondo nodo

Eseguire sul secondo nodo: ./k3sconfig.sh second <token>

• è la stringa visualizzata alla fine dell’esecuzione di " k3sconfig.sh first" sul primo nodo

Lo script:

• Assicurati che il modulo k3s sia avviato come prim sul primo nodo
• Installare k3s sul secondo nodo
• Avviare il modulo k3s

5. Verificare che il modulo k3s SafeKit sia in esecuzione su entrambi i nodi

Verificare con questo comando su entrambi i nodi: /opt/safekit/safekit –H "*" state

La risposta dovrebbe essere simile all’immagine.

/opt/safekit/safekit –H "*" state
---------------- Server= http://10.0.0.20:9010 ----------------
azione admin =esegui
--------------------- Stato di k3s ---------------------

  Locale (127.0.0.1): PRIM (Servizio: Disponibile) (Colore: Verde)
Successo
---------------- Server= http://10.0.0.21:9010 ----------------
azione admin =esegui
--------------------- Stato di k3s ---------------------

  Locale (127.0.0.1): SECOND (Servizio: Disponibile) (Colore: Verde)
Successo

6. Avviare la console web SafeKit per amministrare il cluster

• Connettere un browser all’URL della console web SafeKit http://server0-IP:9010.
• Dovrebbe comparire una pagina simile all’immagine.
• Verificare con le righe di comando Linux che K3S sia avviato su entrambi i nodi (avviato in start_prim e start_second) e che MariaDB sia avviato sul nodo primario (avviato in start_prim).

7. Test

• Arrestare il nodo PRIM scorrendo il relativo menu contestuale e facendo clic su Stop.
• Verificare che sia presente un failover sul SECOND nodo, che dovrebbe diventare ALONE (verde).
• E con le righe di comando su Linux, controllare il failover dei servizi (arrestati sul nodo 1 nello script stop_prim e avviati sul nodo 2 nello script start_prim). MariaDB e K3S dovrebbero essere in esecuzione sul node2.

Se ALONE (verde) non viene raggiunta sul node2, analizzare il motivo con il log del modulo del nodo 2.

• Fare clic su node2 per visualizzare il log del modulo.
• Esempio di un log del modulo SQL Server in cui il nome del servizio in start_prim non è valido. Il processo sqlserver.exe è monitorato ma, poiché non è avviato, alla fine il modulo si arresta.

Se tutto è a posto, avviare il node1, che risincronizzerà le directory replicate dal node2.

Se le cose vanno male, arrestare node2 e forzare l’avvio come primario di node1, che si riavvierà con i suoi dati localmente integri al momento dell’arresto.

🛠️ Maggiori informazioni sui test nella Guida per l’utente.

8. Prova il cluster con un’applicazione Kubernetes come WordPress

Nell’immagine è riportato l’esempio di un’installazione WordPress: un portale web con un database di backend implementato da pod.

È possibile distribuire la propria applicazione nello stesso modo.

WordPress è automaticamente altamente disponibile:

• con i suoi dati (php + database) in volumi persistenti replicati in tempo reale da SafeKit
• con un indirizzo IP virtuale per l’accesso al sito WordPress per gli utenti
• con failover automatico e failback automatico

Note:

• Il grafico di WordPress definisce un servizio con bilanciamento del carico che è in ascolto sulle porte <service.port> e <service.httpsport>.

• WordPress è accessibile tramite l’URL: http://<virtual-ip>:<service.port>.

• L’IP virtuale è gestito da SafeKit e viene commutato automaticamente in caso di failover.

• Per impostazione predefinita, K3S implementa i bilanciatori del carico con Klipper.

• Klipper ascolta su : <service.port> e instrada i pacchetti TCP/IP all’indirizzo IP e alla porta del pod WordPress che ha selezionato.

  $ export KUBECONFIG= /etc/rancher/k3s/k3s.yaml $ helm repo add bitnami https://charts.bitnami.com/bitnami $ helm install my-release bitnami/wordpress –set global.storageClass=nfs-client –set service.ports.http=8099,service.ports.https=4439

Il comando helm precedente dovrebbe scaricare l’immagine WordPress da registry-1.docker.io. Potresti riscontrare problemi di autenticazione su registry-1.docker.io. In questo caso, dovresti:

• creare /etc/rancher/k3s/registries.yaml su entrambi i nodi con all’interno:

  configs:
    "registry-1.docker.io":
      auth:
        username: your_user_name
        password: your_password
      tls:
        insecure_skip_verify: true
  

• Arrestare e avviare k3s per tenere conto delle modifiche, con systemctl stop k3s e systemctl start k3s.

• Eseguire il helm registry login -u your_user_name docker.io, quindi inserire la password

9. Supporto

• Per ottenere assistenza, eseguire 2 Snapshots SafeKit (2 file .zip), uno per ciascun nodo.

🛠️ Risoluzione dei problemi nella Guida per l’utente.

10. Se necessario, configurare un checker split-brain

• Vedere di seguito “Quali sono i diversi scenari in caso di isolamento della rete in un cluster?” per sapere se è necessario configurare un checker split-brain.

• Nella configurazione del modulo, fare clic su Advanced Configuration (vedere l’immagine) per modificare userconfig.xml.

• Dichiarare il checker split-brain aggiungendolo nella sezione <check> di userconfig.xml:

  <service>
   ...
   <check>
    ...
    <splitbrain ident="witness" exec="ping" arg="witness IP"/>
   </check>
  

• Save and apply la nuova configurazione per ridistribuire il file userconfig.xml modificato su entrambi i nodi (il modulo deve essere arrestato su entrambi i nodi per salvare e applicare).

Parametri :

• ident="witness" identifica il witness con un nome di risorsa: splitbrain.witness. È possibile modificare questo valore per identificare il witness.
• exec="ping" fa riferimento al codice ping da eseguire. Non modificare questo valore.
• arg="witness IP" è un argomento per il ping. Modificare questo valore con l’IP del witness (un elemento robusto, in genere un router).

Quali sono i diversi scenari in caso di isolamento della rete in un cluster?

Una singola rete

In caso di isolamento della rete, il comportamento predefinito è:

• quando heartbeat vengono persi per ogni nodo, ogni nodo passa a ALONE ed esegue l’applicazione con il suo indirizzo IP virtuale (doppia esecuzione dell’applicazione che modifica i suoi dati locali),
• quando l’isolamento viene ripristinato, un nodo ALONE è costretto a fermarsi e a risincronizzare i propri dati dall’altro nodo,
• alla fine il cluster è PRIM-SECOND (o SECOND-PRIM in base al rilevamento dell’indirizzo IP virtuale duplicato effettuato da Windows).

Due reti con una rete di replica dedicata

In caso di isolamento della rete, il comportamento con una rete di replica dedicata è il seguente:

• una rete di replica dedicata è implementata su una rete privata,
• Heartbeat sulla rete di produzione vengono persi (rete isolata),
• Heartbeat sulla rete di replica funzionano (non sulla rete isolata),
• Il cluster rimane nello stato PRIM/SECOND.

Una singola rete e un checker split-brain

In caso di isolamento della rete, il comportamento con un checker split-brain è il seguente:

• un checker split-brain è stato configurato con l’indirizzo IP di un witness (in genere un router),
• il checker split-brain si attiva quando un server passa da PRIM a ALONE o da SECOND a ALONE,
• in caso di isolamento della rete, prima di passare ad ALONE, entrambi i nodi testano l’indirizzo IP,
• il nodo che può accedere all’indirizzo IP passa a ALONE, l’altro passa a WAIT,
• Quando l’isolamento viene ripristinato, il nodo WAIT risincronizza i suoi dati e diventa SECOND.

Nota: se il witness è inattivo o disconnesso, entrambi i nodi passano a WAIT e l’applicazione non è più in esecuzione. Ecco perché è necessario scegliere un witness robusto come un router.

Dimostrazione della soluzione mirror SafeKit

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

In questo video, scopri come SafeKit implementa un cluster HA mirror senza la complessità di una SAN. Sebbene questa dimostrazione utilizzi Microsoft SQL Server, la soluzione funziona in modo identico per altri database e applicazioni.

Capitoli

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)

Implementazione passo-passo

• 🛠️ Leggi la guida sulla configurazione di un cluster mirror su Windows
• 🛠️ Leggi la guida su come configurare un cluster mirror su Linux

🔍 Esplora SafeKit

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