diff options
| author | Paul Buetow <paul@buetow.org> | 2024-11-16 23:35:11 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2024-11-16 23:35:11 +0200 |
| commit | 59a7d0c5b74968976d633e737097556b6c38decb (patch) | |
| tree | e3a8233979d21797935a01891d7c5202d84ac94f /gemfeed | |
| parent | fea3ab554253637802a73efd27cc4c782bf4bf36 (diff) | |
Update content for md
Diffstat (limited to 'gemfeed')
| -rw-r--r-- | gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.md | 2 |
1 files changed, 1 insertions, 1 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 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). |