---
title: "K3S hoge beschikbaarheid met SafeKit: Installeer de k3s.safe module voor failover"
canonical: "https://safekit.eviden.com/nl/quick-install/safekit-quick-installation-guide-with-kubernetes/"
description: "Implementeer de k3s.safe module voor SafeKit om synchrone realtime replicatie en automatische failover van Kubernetes op Linux mogelijk te maken. Deze handleiding begeleidt u bij het opzetten van een SANless-cluster met 2 knooppunten voor bedrijfskritieke Linux toepassingen zonder gedeelde opslag."
category: "quick-install"
lang: "nl"
topics: "Snelinstallatiegids voor hoge beschikbaarheid voor Kubernetes, Beperkingen SafeKit High Availability, Overzicht van de SafeKit/Kubernetes-oplossing, Installatie en configuratie van de SafeKit/Kubernetes-oplossing op Linux (k3s.safe), Wat zijn de verschillende scenario's in geval van netwerkisolatie in een cluster?, Demonstratie van de SafeKit mirror"
translation: "translate_md 2026-11-08.15 | glossaire 2026-11-09.11 | Translation LLM | 39 expressions"
---
# K3S hoge beschikbaarheid met SafeKit: Installeer de k3s.safe module voor failover {#k3s-high-availability-with-safekit-install-the-k3ssafe-module-for-failover}
## Snelinstallatiegids voor hoge beschikbaarheid voor Kubernetes {#quick-guide}
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 🤖](https://safekit.eviden.com/nl/resources/safekit-support/) gebruiken.
### 1. Overzicht {#1-overview}
* **Architectuur:** maakt gebruik van een systeem met twee knooppunten (primair/secundair).
* **Gegevensbescherming:** implementeert synchrone replicatie in realtime voor **nul gegevensverlies** (RPO = 0).
### 2. Installatie {#2-installation}
* **Software:** Installeer de SafeKit-engine op beide servers.
* **Module:** Download de vooraf geconfigureerde `k3s.safe`-applicatiemodule.
### 3. Configuratie {#3-configuration}
* **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 {#safekit-ha-limitations}
Limiet / Vereiste | Reden en impact | Aanbevolen alternatief
---|---|---
Replicatiegrootte: een paar TB | Resynchronisatietijd na storing ([stap 3](https://safekit.eviden.com/nl/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)):
• 1 Gb/s-netwerk ≈ 3 uur/TB
• 10 Gb/s-netwerk ≈ 1 uur/TB (afhankelijk van de schrijfsnelheid van de schijf) | • Gebruik [externe gedeelde opslag](https://safekit.eviden.com/nl/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (duurder, complexer).
Aantal bestanden: < 1.000.000 bestanden | • Prestaties van de resynchronisatietijd na een storing ([stap 3](https://safekit.eviden.com/nl/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Tijd die nodig is om elk bestand tussen beide knooppunten te vergelijken. | • Plaats de vele bestanden die u wilt repliceren op een virtuele harde schijf/virtuele machine.
• In dit geval worden alleen de bestanden die de virtuele harde schijf/virtuele machine vertegenwoordigen, gerepliceerd en opnieuw gesynchroniseerd.
Failovercapaciteit: ≤ 32 VM's | • Elke VM draait in een onafhankelijke mirror-module.
• Maximaal 32 mirror-modules die op hetzelfde cluster draaien. | • Gebruik een externe gedeelde opslag en een andere VM-clusteroplossing (duurder, complexer).
Netwerkarchitectuur: LAN/VLAN-netwerk tussen externe locaties | • Automatische failover van het [virtuele IP-adres](https://safekit.eviden.com/nl/best-practises/how-a-virtual-ip-address-works/) met 2 knooppunten in hetzelfde subnet.
• Goede bandbreedte voor resynchronisatie ([stap 3](https://safekit.eviden.com/nl/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Lage latentie voor [synchrone replicatie](https://safekit.eviden.com/nl/best-practises/synchronous-replication-vs-asynchronous-replication/): doorgaans < 5 ms RTT; hogere waarden moeten worden gevalideerd aan de hand van de schrijfsnelheid van de toepassing. | • Als de twee knooppunten zich in verschillende subnets bevinden (gebruikelijk in de cloud), gebruik dan [andere omleidingsopties](https://safekit.eviden.com/nl/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): een load balancer, CLI's van cloudproviders, BGP of DNS-omleiding.
• Gebruik back-upoplossingen met asynchrone replicatie voor netwerken met hoge latentie.
## Overzicht van de SafeKit/Kubernetes-oplossing {#overview-of-the-safekit--kubernetes-solution}
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) {#installation-and-configuration-of-the-safekit--kubernetes-solution-on-linux-k3ssafe}
### 1. Pakketten downloaden {#1-download-packages}
* 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 {#2-first-on-both-nodes}
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 {#3-on-the-first-node}
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 {#4-on-the-second-node}
Voer uit op het tweede knooppunt: `./k3sconfig.sh second `
* 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 {#5-check-that-the-k3s-safekit-module-is-running-on-both-nodes}
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 {#6-start-the-safekit-web-console-to-administer-the-cluster}
* 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 {#7-testing}
* 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 {#8-try-the-cluster-with-a-kubernetes-application-like-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 en .
* WordPress is toegankelijk via de URL: `http://:.`
* 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 : 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 {#9-support}
* 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 {#10-if-necessary-configure-a-splitbrain-checker}
* Zie hieronder ["Wat zijn de verschillende scenario's in geval van netwerkisolatie in een cluster?"](#isolation) 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 ``-sectie van `userconfig.xml`:
...
...
* `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? {#isolation}
### Eén enkel netwerk {#a-single-network}
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 {#two-networks-with-a-dedicated-replication-network}
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 {#a-single-network-and-a-splitbrain-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 {#demonstration-of-the-safekit-mirror-solution}
### SafeKit video: Clustering op applicatieniveau (8:47) {#demo-mirror-ha-cluster}
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 {#chapters}
1. 🎬 [2 knooppunten met SQL Server](https://www.youtube.com/watch?v=mGwEguDnnH0&t=0s) (0:32)
2. 🎬 [Configureer het cluster en de mirror.safe-module](https://www.youtube.com/watch?v=mGwEguDnnH0&t=32s) (3:58)
3. 🎬 [SQL-replicatie, -migratie en -failover bij een crash starten en testen](https://www.youtube.com/watch?v=mGwEguDnnH0&t=270s) (4:17)
### Stapsgewijze implementatie {#step-by-step-implementation}
* 🛠️ [Lees de handleiding voor het instellen van een mirror-cluster op Windows](https://safekit.eviden.com/nl/quick-install/safekit-quick-installation-guide-for-a-new-windows-application-with-real-time-replication-and-failover/)
* 🛠️ [Lees de handleiding voor het instellen van een mirror-cluster op Linux](https://safekit.eviden.com/nl/quick-install/safekit-quick-installation-guide-for-a-new-linux-application-with-real-time-replication-and-failover/)