From 9b0539eb17d1b85cbcaec2a834ea2fb26cd65385 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 16 Nov 2024 23:25:54 +0200 Subject: Update content for gemtext --- gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi | 2 +- gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl | 2 +- gemfeed/atom.xml | 6 ++++-- 3 files changed, 6 insertions(+), 4 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi index 5bcf82ce..1bdd3200 100644 --- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi +++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi @@ -73,7 +73,7 @@ These Linux VMs form a three-node k3s Kubernetes cluster, where my containers wi Persistent storage for the k3s cluster will be handled by highly available (HA) NFS shares backed by ZFS on the FreeBSD hosts. -On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a `pool` ZFS pool. With HAST (FreeBSD's solution for highly available storage), this `pool` will be replicated at the byte level to a standby node. +On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a `zhast` ZFS pool. With HAST (FreeBSD's solution for highly available storage), this `pool` will be replicated at the byte level to a standby node. A virtual IP (VIP) will point to the master node. When the master node goes down, the VIP will failover to the standby node, where the ZFS pool will be mounted. An NFS server will listen to both nodes. k3s will use the VIP to access the NFS shares. diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl index def0fe07..63a24e25 100644 --- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl +++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl @@ -58,7 +58,7 @@ These Linux VMs form a three-node k3s Kubernetes cluster, where my containers wi Persistent storage for the k3s cluster will be handled by highly available (HA) NFS shares backed by ZFS on the FreeBSD hosts. -On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a `pool` ZFS pool. With HAST (FreeBSD's solution for highly available storage), this `pool` will be replicated at the byte level to a standby node. +On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a `zhast` ZFS pool. With HAST (FreeBSD's solution for highly available storage), this `pool` will be replicated at the byte level to a standby node. A virtual IP (VIP) will point to the master node. When the master node goes down, the VIP will failover to the standby node, where the ZFS pool will be mounted. An NFS server will listen to both nodes. k3s will use the VIP to access the NFS shares. diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 2a737106..c59716ea 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2024-11-16T23:20:14+02:00 + 2024-11-16T23:24:56+02:00 foo.zone feed To be in the .zone! @@ -20,6 +20,8 @@

f3s: Kubernetes with FreeBSD - Setting the stage - Part 1



+Published at 2024-11-16T23:20:14+02:00
+
This is the first blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution I will use on FreeBSD-based physical machines.

I will post a new entry every month or so (there are too many other side projects for more frequent updates—I bet you can understand).
@@ -93,7 +95,7 @@
Persistent storage for the k3s cluster will be handled by highly available (HA) NFS shares backed by ZFS on the FreeBSD hosts.

-On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a pool ZFS pool. With HAST (FreeBSD's solution for highly available storage), this pool will be replicated at the byte level to a standby node.
+On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a zhast ZFS pool. With HAST (FreeBSD's solution for highly available storage), this pool will be replicated at the byte level to a standby node.

A virtual IP (VIP) will point to the master node. When the master node goes down, the VIP will failover to the standby node, where the ZFS pool will be mounted. An NFS server will listen to both nodes. k3s will use the VIP to access the NFS shares.

-- cgit v1.2.3