From afe1e4b0ebcb6a117aa9dc781a9ffedb3a807db0 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Wed, 29 Jan 2025 08:03:13 +0200 Subject: Update content for html --- gemfeed/atom.xml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'gemfeed/atom.xml') diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 1a7d9632..04c16049 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2025-01-19T13:21:25+02:00 + 2025-01-29T08:02:28+02:00 foo.zone feed To be in the .zone! @@ -1061,6 +1061,7 @@ dev.cpu.0.freq: 2922
2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage (You are currently reading this)
2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation
+f3s-kubernetes-with f3s: Kubernetes with FreeBSD - Rocky Linux Bhyve VMs - Part 4

f3s logo

@@ -1090,7 +1091,7 @@ dev.cpu.0.freq: 2922
My previous setup was great for learning Terraform and AWS, but it is too expensive. Costs are under control there, but only because I am shutting down all containers after use (so they are offline ninety percent of the time and still cost around $20 monthly). With the new setup, I could run all containers 24/7 at home, which would still be cheaper in terms of electricity consumption. I have a 50 MBit/s uplink (I could have more if I wanted, but it is plenty for my use case already).

-From babylon5.buetow.org to .cloud
+From babylon5.buetow.org to .cloud

Migrating off all my containers from AWS ECS means I need a reliable and scalable environment to host my workloads. I wanted something:

@@ -1149,8 +1150,8 @@ dev.cpu.0.freq: 2922
So, when I want to access a service running in k3s, I will hit an external DNS endpoint (with the authoritative DNS servers being the OpenBSD boxes). The DNS will resolve to the master OpenBSD VM (see my KISS highly-available with OpenBSD blog post), and from there, the relayd process (with a Let's Encrypt certificate—see my Let's Encrypt with OpenBSD and Rex blog post) will accept the TCP connection and forward it through the WireGuard tunnel to a reachable node port of one of the k3s nodes, thus serving the traffic.

-KISS high-availability with OpenBSD
-Let's Encrypt with OpenBSD and Rex
+KISS high-availability with OpenBSD
+Let's Encrypt with OpenBSD and Rex

The OpenBSD setup described here already exists and is ready to use. The only thing that does not yet exist is the configuration of relayd to forward requests to k3s through the WireGuard tunnel(s).

@@ -1190,7 +1191,7 @@ dev.cpu.0.freq: 2922
Alerts generated by Prometheus are forwarded to Alertmanager, which I will configure to work with Gogios, a lightweight monitoring and alerting system I wrote myself. Gogios runs on one of my OpenBSD VMs. At regular intervals, Gogios scrapes the alerts generated in the k3s cluster and notifies me via Email.

-KISS server monitoring with Gogios
+KISS server monitoring with Gogios

Ironically, I implemented Gogios to avoid using more complex alerting systems like Prometheus, but here we go—it integrates well now.

@@ -1219,6 +1220,7 @@ dev.cpu.0.freq: 2922 2024-04-01 KISS high-availability with OpenBSD
2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage (You are currently reading this)
2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation
+f3s-kubernetes-with f3s: Kubernetes with FreeBSD - Rocky Linux Bhyve VMs - Part 4

E-Mail your comments to paul@nospam.buetow.org :-)

-- cgit v1.2.3