K3S hoge beschikbaarheid met SafeKit: Installeer de k3s.safe module voor failover

Snelinstallatiegids voor hoge beschikbaarheid voor Kubernetes

Deze handleiding legt uit hoe u een mirror-cluster voor Kubernetes instelt met SafeKit, wat zorgt voor automatische failover en synchrone replicatie zonder dat er gedeelde opslag nodig is.

Voor hulp kunt u SafeKit AI 🤖 gebruiken.

1. Overzicht

• Architectuur: maakt gebruik van een systeem met twee knooppunten (primair/secundair).
• Gegevensbescherming: implementeert synchrone replicatie in realtime voor nul gegevensverlies (RPO = 0).

2. Installatie

• Software: Installeer de SafeKit-engine op beide servers.
• Module: Download de vooraf geconfigureerde k3s.safe-applicatiemodule.

3. Configuratie

• Webconsole: configureer de specifieke mappen die de Kubernetes bestanden bevatten.
• Monitoren: Begin met het monitoren en beveiligen van de Kubernetes applicatie.

Beperkingen SafeKit High Availability

Overzicht van de SafeKit/Kubernetes-oplossing

De oplossing wordt hier beschreven: 💡 Kubernetes K3s hoge beschikbaarheid: synchrone replicatie en failover met 2 knooppunten

Installatie en configuratie van de SafeKit/Kubernetes-oplossing op Linux (k3s.safe)

1. Pakketten downloaden

• Download de gratis versie van SafeKit 8.2 voor Linux (safekitlinux_xx.bin)
• Download de k3s.safe Linux module
• Download het k3sconfig.sh-script
• Documentatie (pptx)

Opmerking: het script k3sconfig.sh installeert K3S, MariaDB, NFS en SafeKit op 2 Linux Ubuntu 24.04-knooppunten.

SafeKit (Linux) downloaden >

k3s.safe downloaden (Linux) >

k3sconfig.sh downloaden >

Documentatie (pdf) >

2. Eerst op beide knooppunten

Op 2 Linux Ubuntu 24.04-knooppunten, als root:

• Zorg ervoor dat het knooppunt internettoegang heeft (dit kan via een proxy zijn)
• Kopieer k3sconfig.sh, k3s.safe en het safekit_xx.bin-pakket naar een map en ga ernaartoe met cd
• Hernoem het .bin-bestand naar “safekit.bin”
• Zorg ervoor k3sconfig.sh en safekit.bin uitvoerbaar zijn.
• Bewerk het k3sconfig.sh script en pas de omgevingsvariabelen aan uw omgeving aan (inclusief een virtueel IP-adres)
• Voer op beide knooppunten uit: ./k3sconfig.sh prereq

Het script zal:

• Installeer de vereiste Debian-pakketten: alien, nfs-kernel-server, nfs-common, mariadb-server
• Beveiligde MariaDB-installatie
• Mappen aanmaken voor bestandsreplicatie
• Bereid de NFS-server voor op het delen van gerepliceerde mappen
• SafeKit installeren

3. Op het eerste knooppunt

Voer uit op het eerste knooppunt: ./k3sconfig.sh first

Het script zal:

• De K3S-configuratiedatabase en de k3s-gebruiker aanmaken
• Maak het gerepliceerde opslagvolumebestand (sparse file) aan en formatteer het als een xfs-bestandssysteem
• Maak de safekit-clusterconfiguratie aan en pas deze toe
• Installeer en configureer de k3s.safe module op het cluster
• Start de k3s-module als “prim” op de eerste node
• k3s downloaden, installeren en starten
• Download en installeer de Helm-chart van nfs-subdir-external-provisioner
• K3S token weergeven (te gebruiken tijdens de installatiefase van het tweede knooppunt)

4. Op de tweede node

Voer uit op het tweede knooppunt: ./k3sconfig.sh second <token>

• is de tekenreeks die wordt weergegeven aan het einde van de uitvoering van " k3sconfig.sh first" op de eerste node

Het script zal:

• Zorg ervoor dat de k3s-module als prim wordt gestart op het eerste knooppunt
• Installeer k3s op de tweede node
• Start de k3s-module

5. Controleer of de k3s SafeKit module op beide knooppunten draait

Controleer dit met deze opdracht op beide knooppunten: /opt/safekit/safekit –H "*" state

Het antwoord moet vergelijkbaar zijn met de afbeelding.

/opt/safekit/safekit –H "*" state
---------------- Server= http://10.0.0.20:9010 ----------------
admin action=exec
--------------------- k3s-status ---------------------

  Lokaal (127.0.0.1): PRIM (Service: Beschikbaar) (Kleur: Groen)
Succes
---------------- Server= http://10.0.0.21:9010 ----------------
admin action=exec
--------------------- k3s-status ---------------------

  Lokaal (127.0.0.1): SECOND (Service: Beschikbaar) (Kleur: Groen)
Succes

6. Start de SafeKit webconsole om het cluster te beheren

• Maak verbinding met de SafeKit webconsole via de URL http://server0-IP:9010.
• U zou een pagina moeten zien die lijkt op de afbeelding.
• Controleer met Linux opdrachtregels of K3S op beide knooppunten is gestart (gestart in start_prim en start_second) en dat MariaDB is gestart op het primaire knooppunt (gestart in start_prim).

7. Testen

• Stop de PRIM node door in het contextmenu naar beneden te scrollen en Stop te klikken.
• Controleer of er een failover is op het SECOND knooppunt, dat ALONE (groen) zou moeten worden.
• Controleer met de opdrachtregels op Linux de failover van services (gestopt op node 1 in het stop_prim-script en gestart op node 2 in het start_prim script). MariaDB en K3S moeten op node2 draaien.

Als ALONE (groen) niet wordt bereikt op node2, analyseer dan waarom met het modullogboek van node 2.

• Klik op node2 om het modulelogboek weer te geven.
• Voorbeeld van een SQL Server-moduillogboek waarin de servicenaam in start_prim ongeldig is. Het proces sqlserver.exe wordt gemonitord, maar omdat het niet wordt gestart, stopt de module uiteindelijk.

Als alles in orde is, start u node1 op, die de gerepliceerde mappen van node2 opnieuw synchroniseert.

Als er iets misgaat, stop dan node2 en forceer de start als primair van node1, die opnieuw zal opstarten met zijn lokaal gezonde gegevens op het moment van de stop.

🛠️ Meer informatie over de tests vindt u in de gebruikershandleiding.

8. Probeer het cluster met een Kubernetes-applicatie zoals WordPress

In de afbeelding ziet u het voorbeeld van een WordPress-installatie: een webportaal met een backend-database die is geïmplementeerd door pods.

U kunt uw eigen applicatie op dezelfde manier implementeren.

WordPress is automatisch zeer beschikbaar:

• met zijn gegevens (php + database) in persistente volumes die in realtime worden gerepliceerd door SafeKit
• met een virtueel IP-adres om toegang te krijgen tot de WordPress-site voor gebruikers
• met automatische failover en automatische failback

Opmerkingen:

• De WordPress-chart definieert een load-balanced service die luistert op poorten <service.port> en <service.httpsport>.

• WordPress is toegankelijk via de URL: http://<virtual-ip>:<service.port>.

• Het virtuele IP-adres wordt beheerd door SafeKit en wordt automatisch overgeschakeld in geval van een failover.

• Standaard implementeert K3S load balancers met Klipper.

• Klipper luistert op : <service.port> en stuurt de TCP/IP-pakketten door naar het IP-adres en de poort van de WordPress-pod die het heeft geselecteerd.

  $ 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

De vorige helm-opdracht zou de WordPress-image moeten downloaden van registry-1.docker.io. Mogelijk ondervindt u authenticatieproblemen op registry-1.docker.io. In dat geval moet u het volgende doen:

• Maak /etc/rancher/k3s/registries.yaml aan op beide nodes met de volgende inhoud:

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

• Stop en start k3s om dit door te voeren, met systemctl stop k3s en systemctl start k3s.

• Voer helm registry login -u your_user_name docker.io uit en voer vervolgens uw wachtwoord in

9. Ondersteuning

• Om ondersteuning te krijgen, maakt u 2 SafeKit Snapshots (2 .zip-bestanden), één voor elke node.

🛠️ Probleemoplossing in de gebruikershandleiding.

10. Configureer indien nodig een split-brain-checker

• Zie hieronder “Wat zijn de verschillende scenario’s in geval van netwerkisolatie in een cluster?” om te weten of u een split-brain-checker moet configureren.

• Klik in de moduleconfiguratie op Advanced Configuration (zie afbeelding) om userconfig.xml te bewerken.

• Declareer de split-brain-checker door deze toe te voegen aan de <check>-sectie van userconfig.xml:

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

• Save and apply om het gewijzigde userconfig.xml bestand opnieuw te implementeren op beide knooppunten (de module moet op beide knooppunten worden gestopt om op te slaan en toe te passen).

Parameters:

• ident="witness" identificeert de witness met een resourcenaam: splitbrain.witness. U kunt deze waarde wijzigen om de witness te identificeren.
• exec="ping" verwijst naar de pingcode die moet worden uitgevoerd. Wijzig deze waarde niet.
• arg="witness IP" is een argument voor de ping. Wijzig deze waarde met het IP-adres van de witness (een robuust element, meestal een router).

Wat zijn de verschillende scenario’s in geval van netwerkisolatie in een cluster?

Eén enkel netwerk

Bij netwerkisolatie is het standaardgedrag:

• als heartbeats verloren gaan voor elke node, gaat elke node naar ALONE en voert de applicatie uit met zijn virtuele IP-adres (dubbele uitvoering van de applicatie die zijn lokale gegevens wijzigt),
• wanneer de isolatie is hersteld, wordt één ALONE node gedwongen te stoppen en zijn gegevens opnieuw te synchroniseren met de andere node,
• Uiteindelijk is de cluster PRIM-SECOND (of SECOND-PRIM, afhankelijk van de detectie van het dubbele virtuele IP-adres door Windows).

Twee netwerken met een speciaal replicatienetwerk

Bij netwerkisolatie is het gedrag met een speciaal replicatienetwerk als volgt:

• een speciaal replicatienetwerk wordt geïmplementeerd op een privénetwerk,
• Heartbeats op het productienetwerk gaan verloren (geïsoleerd netwerk),
• Heartbeats op het replicatienetwerk werken (geen geïsoleerd netwerk),
• Het cluster blijft in PRIM/SECOND status.

Eén netwerk en een split-brain-checker

Bij netwerkisolatie is het gedrag met een split-brain-checker als volgt:

• een split-brain-checker is geconfigureerd met het IP-adres van een witness (doorgaans een router),
• De split-brain-checker wordt geactiveerd wanneer een server van PRIM naar ALONE gaat of van SECOND naar ALONE
• In geval van netwerkisolatie testen beide knooppunten het IP-adres voordat ze naar ALONE gaan
• De node die toegang heeft tot het IP-adres gaat naar ALONE, de andere gaat naar WAIT
• Wanneer de isolatie is hersteld, synchroniseert de WAIT node zijn gegevens opnieuw en wordt SECOND.

Opmerking: Als de witness uitvalt of de verbinding wordt verbroken, gaan beide nodes naar WAIT en wordt de applicatie niet meer uitgevoerd. Daarom moet u een robuuste witness kiezen, zoals een router.

Demonstratie van de SafeKit mirror

SafeKit video: Clustering op applicatieniveau (8:47)

Ontdek in deze video hoe SafeKit een mirror HA-cluster implementeert zonder de complexiteit van een SAN. Hoewel deze demonstratie gebruikmaakt van Microsoft SQL Server, werkt de oplossing identiek voor andere databases en toepassingen.

Hoofdstukken

1. 🎬 2 knooppunten met SQL Server (0:32)
2. 🎬 Configureer het cluster en de mirror.safe-module (3:58)
3. 🎬 SQL-replicatie, -migratie en -failover bij een crash starten en testen (4:17)

Stapsgewijze implementatie

• 🛠️ Lees de handleiding voor het instellen van een mirror-cluster op Windows
• 🛠️ Lees de handleiding voor het instellen van een mirror-cluster op Linux

🔍 Ontdek SafeKit

Vind informatie over de functies, architecturen, video’s, documentatie en de gratis proefversie van SafeKit.