From 59a7d0c5b74968976d633e737097556b6c38decb Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 16 Nov 2024 23:35:11 +0200 Subject: Update content for md --- gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'gemfeed') 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 1020685c..524b7c70 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 @@ -92,7 +92,7 @@ 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](https://foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html) -[Le's Encrypt with OpenBSD and Rex](https://foo.zone/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html) +[Let's Encrypt with OpenBSD and Rex](https://foo.zone/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html) 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). -- cgit v1.2.3