From 36227f09dd96ee54e13f581f2286e6594d8c2136 Mon Sep 17 00:00:00 2001
From: Paul Buetow
Date: Sun, 8 Feb 2026 22:39:32 +0200
Subject: Update content for html
---
gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
(limited to 'gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html')
diff --git a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html
index 9bb66851..b94b51cb 100644
--- a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html
+++ b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html
@@ -13,7 +13,7 @@
f3s: Kubernetes with FreeBSD - Part 6: Storage
-Published at 2025-07-13T16:44:29+03:00, last updated: 27.01.2026
+Published at 2025-07-13T16:44:29+03:00, last updated Tue 27 Jan 10:09:08 EET 2026
This is the sixth blog post about the f3s series for self-hosting demands in a home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution used on FreeBSD-based physical machines.
@@ -86,7 +86,7 @@
Introduction
-In the previous posts, we set up a WireGuard mesh network. In the future, we will also setting up a Kubernetes cluster. Kubernetes workloads often require persistent storage for databases, configuration files, and application data. Local storage on each node has significant limitations:
+In the previous posts, we set up a WireGuard mesh network. In the future, we will also set up a Kubernetes cluster. Kubernetes workloads often require persistent storage for databases, configuration files, and application data. Local storage on each node has significant limitations:
- No data sharing: Pods (once we run Kubernetes) on different nodes can't access the same data
@@ -500,13 +500,13 @@ EOF
- f0_to_f1_nfsdata: Replicates NFS data every minute for faster failover recovery
- f0_to_f1_freebsd: Replicates FreeBSD VM every ten minutes (less critical)
-The FreeBSD VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases, hows zrepl's flexibility in handling different datasets with varying replication needs.
+The FreeBSD VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases how zrepl's flexibility in handling different datasets with varying replication needs.
Furthermore:
- We're specifically replicating zdata/enc/nfsdata instead of the entire zdata/enc dataset. This dedicated dataset will contain all the data we later want to expose via NFS, keeping a clear separation between replicated NFS data and other local encrypted data.
-- The send: encrypted: false option turns off ZFS native encryption for the replication stream. Since we're using a WireGuard tunnel between f0 and f1, the data is already encrypted in transit. Disabling ZFS stream encryption reduces CPU overhead and improves replication performance.
+- We use send: encrypted: true to keep the replication stream encrypted. While WireGuard already encrypts in transit, this provides additional protection. For reduced CPU overhead, you could set encrypted: false since the tunnel is secure.
Configuring zrepl on f1 (sink)
--
cgit v1.2.3