diff options
| author | Paul Buetow <paul@buetow.org> | 2025-01-29 08:05:23 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2025-01-29 08:05:23 +0200 |
| commit | 1966f87b266f093fb5a46a6f09e0b63041dc88a1 (patch) | |
| tree | 0cbfae5ffc0dbb2b9301b7eb9c1a84a6065de058 /gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md | |
| parent | 1798a57ca2e813b5523107576b57ee1d7f00699e (diff) | |
Update content for md
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.md | 8 |
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. |
