Kubernetes K3s hoge beschikbaarheid: synchrone replicatie en failover met 2 knooppunten

K3s HA vereenvoudigen: Waarom SafeKit kiezen boven MetalLB en Longhorn?

Hoewel de standaard open-source stack (MetalLB + Longhorn) voor K3s krachtig is voor grote datacenters, introduceert deze overmatige complexiteit voor on-premises sites met 2 knooppunten. SafeKit vereenvoudigt de K3s-omgeving door op zichzelf staande netwerk- en opslagtools te vervangen door één enkele, geconsolideerde HA-engine.

Waarom SafeKit voor hoge beschikbaarheid (HA) met 2-node K3s?

• Echte hoge beschikbaarheid met 2 knooppunten: SafeKit biedt volledige redundantie met slechts 2 knooppunten, waardoor de vereiste van 3 knooppunten voor etcd- quorum wordt geëlimineerd.
• Geen gegevensverlies (RPO = 0): vervangt opslag met hoge overhead door synchrone replicatie op byte-niveau voor lokale SSD-prestaties.
• Flexibele bescherming op bestandsniveau: SafeKit voert hostgebaseerde replicatie uit op bestandsniveau, wat volledig transparant is voor de toepassing. Het beschermt niet alleen databases, maar ook alle bijbehorende mappen en gegevens. U kunt bestaande mappen precies daar repliceren waar ze zijn geïnstalleerd, zelfs op de systeemdisk.
• Geïntegreerde virtuele IP (VIP): beheert de cluster-IP standaard op kernelniveau, waardoor afzonderlijke MetalLB- configuraties overbodig worden.
• Automatische failover en failback: Activeert een onmiddellijke overgang naar de secundaire node bij een storing; zodra de primaire node weer operationeel is, voert SafeKit een automatische gegevensresynchronisatie uit zonder handmatige tussenkomst.
• Extreem lage overhead: SafeKit werkt zonder de zware beheersoverhead van opslagpods (CSI/Longhorn) en netwerkpods (CNI/MetalLB) die vereist zijn voor standaardstacks, waardoor kritiek RAM- en CPU-geheugen vrijkomt voor uw applicaties.
• IT-generalistvriendelijk: vervangt complexe infrastructuur-YAML voor netwerken en opslag door een eenvoudige web-GUI en geautomatiseerde implementatiescripts, zodat u zich alleen op uw applicaties hoeft te richten.

Shared-nothing high availability (HA) voor K3s-clusters met 2 nodes

⚡ Snelle installatiegids Kubernetes HA-cluster >

Inhoudsopgave

• Hoe implementeert de SafeKit-software eenvoudig een Kubernetes K3s-cluster met hoge beschikbaarheid?
• Hoe werkt het SafeKit mirror-cluster met Kubernetes K3S?
• Beperkingen SafeKit High Availability
• Vergelijking: SafeKit versus standaard K3s-stack (MetalLB & Longhorn)
• Videogids: Een SafeKit mirror HA-cluster configureren
• 🔍 Ontdek SafeKit

Hoe implementeert de SafeKit-software eenvoudig een Kubernetes K3s-cluster met hoge beschikbaarheid?

Hoe implementeer ik hoge beschikbaarheid voor een Kubernetes K3s-cluster met 2 knooppunten?

U kunt hoge beschikbaarheid (HA) implementeren voor een Kubernetes K3s-cluster met 2 knooppunten met behulp van de SafeKit k3s.safe mirror-module. Met deze oplossing kunt u een redundante omgeving implementeren zonder dat u externe NFS-opslag, een speciale externe configuratiedatabase of gespecialiseerde Kubernetes expertise nodig hebt.

Waarom K3s gebruiken voor edge- en IoT-computing?

K3s is de voorkeurs Kubernetes engine voor IoT en edgecomputing, omdat het een lichtgewicht, gecertificeerde distributie is die is ontworpen voor omgevingen met beperkte middelen. Het vereenvoudigt de operationele overhead van standaard Kubernetes met behoud van volledige compatibiliteit.

Wat zijn de belangrijkste kenmerken van de k3s.safe mirror-module?

De k3s.safe module biedt een uitgebreide HA-stack voor K3s door het volgende te implementeren:

• Dubbele actieve knooppunten: Voert 2 actieve K3s-masters/agents tegelijkertijd uit om pods te hosten.
• Database-replicatie: real-time replicatie van de MariaDB-configuratiedatabase tussen knooppunten.
• Permanente opslag: Replicatie van permanente volumes via een geïntegreerde NFS-client dynamische provisioner (nfs-client).
• Netwerkcontinuïteit: Inclusief een virtueel IP-adres voor naadloze clienttoegang.
• Geautomatiseerd herstel: Volledige ondersteuning voor automatische failover en failback.

Welke applicaties en omgevingen kan SafeKit beschermen, naast K3s?

SafeKit is een veelzijdige high-availability-oplossing voor zowel Windows als Linux die veel verder gaat dan een K3s- mirror-cluster. Het maakt synchrone real-time replicatie en automatische failover mogelijk voor een breed scala aan bedrijfskritische workloads, waaronder:

• Virtuele en fysieke omgevingen: complete Hyper-V of KVM virtuele machines.
• Containerorkestratie: Docker, Podman omgevingen.
• Gegevens en diensten: Individuele bestandsmappen, diensten en diverse databases.
• Cloudinfrastructuur: hoge beschikbaarheid voor cloudtoepassingen.

SafeKit biedt farm-clusters ook native netwerktaakverdeling en failover voor stateless applicaties zoals webservers.

💡 Bekijk hier de volledige lijst met ondersteunde HA-oplossingen.

Hoe bereikt SafeKit de hoge beschikbaarheid van K3s?

Architectuur en redundantielogica voor een K3s-cluster met 2 knooppunten met behulp van SafeKit

Automatisch failovermechanisme: In het geval van een storing van de primaire node migreert SafeKit automatisch de virtuele IP’s en opslagservices naar de secundaire node, waardoor een ononderbroken service voor het K3s-cluster wordt gegarandeerd.

Hoe werkt het SafeKit mirror-cluster met Kubernetes K3S?

Stap 1: Bestandsreplicatie op byte-niveau in een mirror-cluster

Deze fase illustreert de high-availability-architectuur tussen server 1 (PRIM) en server 2 (SECOND). Beide servers draaien K3s master- en agentcomponenten zoals gedefinieerd in de architectuurtabel.

Momenteel zijn de Virtual IP (VIP), de persistente NFS-opslag en MariaDB alleen actief op server 1 (PRIM). De K3s-mastercomponenten op beide knooppunten synchroniseren met elkaar door de clusterstatus te benaderen via de Virtual IP en de MariaDB poort. SafeKit implementeert synchrone replicatie van MariaDB en persistente NFS-bestanden, wat garant staat voor nul gegevensverlies (RPO = 0) in geval van een storing.

De K3s-masters verdelen de werklast over beide (of meer) nodes door rechtstreeks te communiceren met de K3s-agents. Externe clients maken verbinding met de
Het virtuele IP-adres van het cluster op de PRIM node. Met behulp van standaard Kubernetes mechanismen stuurt de K3s-master het verkeer door naar pods die over de nodes zijn verdeeld. Op vergelijkbare wijze hebben pods toegang tot hun persistente volumes (PV’s) op de PRIM server via het virtuele IP-adres en de NFS-poort.

Stap 2: Automatische failover en servicecontinuïteit

Wanneer server 1 (PRIM) uitvalt, neemt server 2 (SECOND) automatisch de clusteractiviteiten over om de continuïteit te waarborgen.

SafeKit detecteert de storing en migreert het virtuele IP-adres van het cluster onmiddellijk naar Server 2. Vervolgens worden de lokale MariaDB en NFS-services naar een actieve status gepromoveerd. Vanwege de synchrone replicatie die in stap 1 is uitgevoerd, zijn alle MariaDB databases en NFS Persistent Volume (PV)-bestanden al bijgewerkt op Server 2, waardoor gegevensverlies wordt voorkomen.

Met behoud van de clusterstatus blijft de K3s Master op Server 2 de uitvoering voortzetten. Deze detecteert het verlies van de agent op Server 1 en plant de getroffen pods automatisch opnieuw in op de resterende actieve K3s-agents. De totale failovertijd (RTO) is de som van het foutdetectie-interval (standaard: 30 seconden) en de tijd die nodig is voor de initialisatie van K3s-componenten op de secundaire node.

Terwijl server 1 offline is, blijven MariaDB en NFS-services op server 2 draaien en worden wijzigingen alleen lokaal opgeslagen.

Stap 3: Failback en automatische reintegratie

Failback vindt plaats wanneer Server 1 opnieuw wordt opgestart nadat het oorspronkelijke probleem is opgelost. SafeKit synchroniseert de MariaDB en NFS-bestanden automatisch opnieuw, waarbij alleen de gegevens worden bijgewerkt die op Server 2 zijn gewijzigd tijdens de downtime. Dit herintegratieproces is niet-disruptief; de K3s master- en agentcomponenten blijven zonder onderbreking op Server 2 draaien.

SafeKit optimaliseert de hersteltijd op basis van de manier waarop de server is gestopt:

• Schone afsluiting: Als SafeKit opzettelijk is gestopt op Server 1, worden alleen de specifieke gewijzigde zones binnen de bestanden opnieuw gesynchroniseerd met behulp van modificatietrackingsbitmaps. Dit zorgt voor een ultrasnelle reintegratie.
• Systeemcrash (bijv. stroomstoring): Als Server 1 een onverwachte afsluiting heeft ondergaan, worden de modificatiebitmaps om veiligheidsredenen omzeild. SafeKit synchroniseert in plaats daarvan alle bestanden met een wijzigingstijdstempel die recenter is dan het laatst vastgestelde synchronisatiepunt, waardoor de totale gegevensintegriteit wordt gewaarborgd.

Stap 4: Hoge beschikbaarheid en taakverdeling herstellen

Na de reintegratie keert de cluster terug naar de volledige mirror, die de status van stap 1 weerspiegelt. Het systeem is opnieuw in een zeer beschikbare toestand: MariaDB en NFS-services blijven actief op server 2, terwijl SafeKit alle bestandsupdates in realtime repliceert naar server 1.

De K3s Master en K3s Agent worden automatisch opnieuw opgestart op Server 1. De Kubernetes-scheduler herkent Server 1 nu als een gezond knooppunt en kan beginnen met het opnieuw plannen van pods om de werklast over beide servers te verdelen.

Als de beheerder de voorkeur geeft aan het uitvoeren van de MariaDB en NFS-services op Server 1 (waarbij de oorspronkelijke PRIM rol wordt hersteld), kan een overschakeling handmatig worden geactiveerd via de webconsole op een geschikt moment of geautomatiseerd via de configuratie-instellingen.

Hoe configureer ik een SafeKit mirror-cluster?

De SafeKit webconsole biedt een intuïtieve interface om hoge beschikbaarheid voor uw bedrijfskritische applicaties te orkestreren. In slechts een paar stappen kunt u een SafeKit mirror-cluster configureren om bedrijfscontinuïteit te garanderen:

• Failover van applicaties (tabblad Macro’s): Definieer de specifieke applicatiediensten die automatisch opnieuw moeten worden gestart in geval van een storing.
• Heartbeatnetwerk(en): Toegewezen communicatiepad(en) die door clusterknooppunten worden gebruikt om de status en beschikbaarheid van elkaar continu te controleren en failoverbeslissingen te synchroniseren.
• Virtueel IP-beheer: Stel het virtuele IP-adres (VIP) in voor een transparante herverbinding van de client na een failover.
• Realtime replicatie: Selecteer de kritieke mappen voor hostgebaseerde, synchrone replicatie op byteniveau.
• Checkers: controleer de status van de toepassing en activeer automatisch herstel als er een procesfout wordt gedetecteerd.

Het SafeKit cluster bevat een speciale split-brain-checker om netwerkisolatieproblemen op te lossen zonder dat er een derde ‘witness’-machine of een extra ‘heartbeat’-netwerk nodig is. Lees meer over ‘heartbeat’, ‘failover’ en ‘quorum’ in een cluster.

Hoe kan ik een SafeKit mirror-cluster monitoren?

De SafeKit beheerconsole biedt een uniform overzicht van uw hoge beschikbaarheidsinfrastructuur. Hiermee kunnen beheerders de operationele status van het cluster controleren en de gegevenssynchronisatie in realtime volgen.

Voor een mirror-cluster met 2 knooppunten geeft de console duidelijk de rollen van elke server weer:

• PRIM (primair): de actieve node die momenteel de toepassing uitvoert en het virtuele IP-adres beheert. Deze voert schrijfbewerkingen uit naar de lokale opslag en realtime-replicatie naar de secundaire node.
• SECOND: Het stand-byknooppunt ontvangt synchrone updates op byteniveau. Het is direct klaar om het over te nemen als het primaire knooppunt uitvalt.
• ALONE status: Geeft een visuele waarschuwing wanneer het cluster op één knooppunt draait (bijv. tijdens onderhoud of na een storing), wat aangeeft dat de redundantie tijdelijk verloren is gegaan.
• Voortgang van de resynchronisatie: Wanneer een defecte node herstelt, wordt de status oranje tijdens de achtergrondgegevensreïntegratie, zodat er geen downtime is tijdens de fase ’terug naar normaal’.

Naast eenvoudige statuspictogrammen biedt de interface failover-orkestratie met één klik, zodat u de primaire rol handmatig kunt toewijzen voor gepland onderhoud, terwijl u de continue beschikbaarheid voor gebruikersactiviteiten waarborgt.

Beperkingen SafeKit High Availability

Vergelijking: SafeKit versus standaard K3s-stack (MetalLB & Longhorn)

Vergelijking: SafeKit versus standaard open-source (MetalLB + Longhorn)

Samenvattend biedt een standaard doe-het-zelf-stack (MetalLB + Longhorn) modulariteit voor Kubernetes experts, maar creëert het een circulaire afhankelijkheid waarbij de opslag- en netwerkinstrumenten kwetsbaar zijn voor dezelfde knooppuntstoringen die ze moeten beheren. SafeKit doorbreekt deze lus door te opereren als een onafhankelijke infrastructuurlaag; het biedt een robuustere, hardware-agnostische 2-knoops HA-oplossing die operationeel blijft, zelfs als de Kubernetes-engine of het host-besturingssysteem vastloopt. Dit zorgt voor geautomatiseerd herstel en gegevensintegriteit zonder de zware resourceoverhead, het verplichte drieknoopsquorum of de configuratiecomplexiteit die vereist is door traditionele gedistribueerde blokopslag en netwerkoverlays.

Videogids: Een SafeKit HA- mirror-cluster configureren

SafeKit video: Clustering op applicatieniveau (8:47)

Hoewel deze video de hoge beschikbaarheid van SafeKit voor Microsoft SQL Server demonstreert, geeft het een uitstekend overzicht van hoe de oplossing K3s-omgevingen beveiligt. SafeKit functioneert identiek voor elke andere database of bedrijfskritische toepassing.

Videohoogtepunten

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)

<br />

🔍 Ontdek SafeKit

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