summaryrefslogtreecommitdiff
path: root/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md
diff options
context:
space:
mode:
Diffstat (limited to 'gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md')
-rw-r--r--gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md
index 25cdc7c4..1314bfcd 100644
--- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md
+++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md
@@ -39,7 +39,7 @@ Let's begin...
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`](./2024-02-04-from-babylon5.buetow.org-to-.cloud.html)
+[From `babylon5.buetow.org` to `.cloud`](./2024-02-04-from-babylon5.buetow.org-to-.cloud.md)
Migrating off all my containers from AWS ECS means I need a reliable and scalable environment to host my workloads. I wanted something:
@@ -97,8 +97,8 @@ All of this (every Linux VM to every OpenBSD box) will be connected via WireGuar
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](./2024-04-01-KISS-high-availability-with-OpenBSD.html)
-[Let's Encrypt with OpenBSD and Rex](./2022-07-30-lets-encrypt-with-openbsd-and-rex.html)
+[KISS high-availability with OpenBSD](./2024-04-01-KISS-high-availability-with-OpenBSD.md)
+[Let's Encrypt with OpenBSD and Rex](./2022-07-30-lets-encrypt-with-openbsd-and-rex.md)
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).
@@ -138,7 +138,7 @@ For visualization, Grafana will be deployed alongside Prometheus. Grafana lets m
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](./2023-06-01-kiss-server-monitoring-with-gogios.html)
+[KISS server monitoring with Gogios](./2023-06-01-kiss-server-monitoring-with-gogios.md)
Ironically, I implemented Gogios to avoid using more complex alerting systems like Prometheus, but here we go—it integrates well now.