From 2dd63e372ff66737ee8b56d8bc64b23ea9ded184 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Thu, 5 Feb 2026 21:37:45 +0200 Subject: Update content for html --- ...5-10-02-f3s-kubernetes-with-freebsd-part-7.html | 24 ++++++++++++-------- gemfeed/atom.xml | 26 +++++++++++++--------- 2 files changed, 31 insertions(+), 19 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2025-10-02-f3s-kubernetes-with-freebsd-part-7.html b/gemfeed/2025-10-02-f3s-kubernetes-with-freebsd-part-7.html index d8081dd4..c38ee531 100644 --- a/gemfeed/2025-10-02-f3s-kubernetes-with-freebsd-part-7.html +++ b/gemfeed/2025-10-02-f3s-kubernetes-with-freebsd-part-7.html @@ -47,6 +47,13 @@
  • ⇢ ⇢ Automatic failover when f3s cluster is down
  • ⇢ ⇢ OpenBSD httpd fallback configuration
  • ⇢ Exposing services via LAN ingress
    • +
  • ⇢ ⇢ Architecture overview
    • +
  • ⇢ ⇢ Installing cert-manager
    • +
  • ⇢ ⇢ Configuring FreeBSD relayd for LAN access
    • +
  • ⇢ ⇢ Adding LAN ingress to services
    • +
  • ⇢ ⇢ Client-side DNS and CA setup
    • +
  • ⇢ ⇢ Scaling to other services
    • +
  • ⇢ ⇢ TLS offloaders summary
  • ⇢ Deploying the private Docker image registry
  • ⇢ ⇢ Prepare the NFS-backed storage
  • ⇢ ⇢ Install (or upgrade) the chart
    • @@ -901,7 +908,7 @@ http://www.gnu.org/software/src-highlite -->
    The LAN ingress architecture leverages the existing FreeBSD CARP (Common Address Redundancy Protocol) failover infrastructure that's already in place for NFS-over-TLS (see Part 5). Instead of deploying MetalLB or another LoadBalancer implementation, we reuse the CARP virtual IP (192.168.1.138) by adding HTTP/HTTPS forwarding alongside the existing stunnel service on port 2323.

    -*Architecture overview*:
    +

    Architecture overview



    The LAN access path differs from external access:

    @@ -930,7 +937,7 @@ LAN → FreeBSD CARP VIP (192.168.1.138)
  • CARP provides automatic failover between f0 and f1
  • No code changes to applications—just add a LAN ingress resource

    • -*Installing cert-manager*:
    +

    Installing cert-manager



    First, install cert-manager to handle certificate lifecycle management for LAN services. The installation is automated with a Justfile:

    @@ -984,7 +991,7 @@ http://www.gnu.org/software/src-highlite --> kubectl apply -f -
    -*Configuring FreeBSD relayd for LAN access*:
    +

    Configuring FreeBSD relayd for LAN access



    On both FreeBSD hosts (f0, f1), install and configure relayd for TCP forwarding:

    @@ -1013,7 +1020,7 @@ relay "lan_https" { }
    -Note: The IP addresses 192.168.1.120-122 are the LAN IPs of the k3s nodes (r0, r1, r2), not their WireGuard IPs. FreeBSD relayd requires PF (Packet Filter) to be enabled. Create a minimal /etc/pf.conf:
    +Note: The IP addresses 192.168.1.120-122 are the LAN IPs of the k3s nodes (r0, r1, r2), not their WireGuard IPs. FreeBSD relayd requires PF (Packet Filter) to be enabled. Create a minimal /etc/pf.conf:

     # Basic PF rules for relayd
@@ -1047,7 +1054,7 @@ _relayd  relayd   2903  12
 Repeat the same configuration on f1. Both hosts will run relayd listening on the CARP VIP, but only the CARP MASTER will respond to traffic. When failover occurs, the new MASTER takes over seamlessly.
    
 
    
-*Adding LAN ingress to services*:
    
+
    Adding LAN ingress to services

    
 
    
 To expose a service on the LAN, add a second Ingress resource to its Helm chart. Here's an example:
    
 
    
@@ -1102,7 +1109,7 @@ HTTP/2 302
 location: /app/

    -*Client-side DNS and CA setup*:
    +

    Client-side DNS and CA setup



    To access LAN services, clients need DNS entries and must trust the self-signed CA.

    @@ -1142,14 +1149,13 @@ $ sudo update-ca-trust
    After trusting the CA, browsers will accept the LAN certificates without warnings.

    -*Scaling to other services*:
    +

    Scaling to other services



    The same pattern can be applied to any service. To add LAN access:

    1. Copy the f3s-lan-tls secret to the service's namespace (if not already there)
    2. Add a LAN Ingress resource using the pattern above
    3. Configure DNS: 192.168.1.138 service.f3s.lan.foo.zone
    -4. Commit and push (ArgoCD will deploy automatically)

    No changes needed to:

    @@ -1158,7 +1164,7 @@ $ sudo update-ca-trust
  • cert-manager (wildcard cert covers all *.f3s.lan.foo.zone)
  • CARP configuration (VIP shared by all services)

    • -*TLS offloaders summary*:
    +

    TLS offloaders summary



    The f3s infrastructure now has three distinct TLS offloaders:

    diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 84118011..ae6f88b2 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2026-02-05T21:12:19+02:00 + 2026-02-05T21:36:44+02:00 foo.zone feed To be in the .zone! @@ -4395,6 +4395,13 @@ p hash.values_at(:a, :c)
  • ⇢ ⇢ Automatic failover when f3s cluster is down
  • ⇢ ⇢ OpenBSD httpd fallback configuration
  • ⇢ Exposing services via LAN ingress
    • +
  • ⇢ ⇢ Architecture overview
    • +
  • ⇢ ⇢ Installing cert-manager
    • +
  • ⇢ ⇢ Configuring FreeBSD relayd for LAN access
    • +
  • ⇢ ⇢ Adding LAN ingress to services
    • +
  • ⇢ ⇢ Client-side DNS and CA setup
    • +
  • ⇢ ⇢ Scaling to other services
    • +
  • ⇢ ⇢ TLS offloaders summary
  • ⇢ Deploying the private Docker image registry
  • ⇢ ⇢ Prepare the NFS-backed storage
  • ⇢ ⇢ Install (or upgrade) the chart
    • @@ -5249,7 +5256,7 @@ http://www.gnu.org/software/src-highlite -->
    The LAN ingress architecture leverages the existing FreeBSD CARP (Common Address Redundancy Protocol) failover infrastructure that's already in place for NFS-over-TLS (see Part 5). Instead of deploying MetalLB or another LoadBalancer implementation, we reuse the CARP virtual IP (192.168.1.138) by adding HTTP/HTTPS forwarding alongside the existing stunnel service on port 2323.

    -*Architecture overview*:
    +

    Architecture overview



    The LAN access path differs from external access:

    @@ -5278,7 +5285,7 @@ LAN → FreeBSD CARP VIP (192.168.1.138)
  • CARP provides automatic failover between f0 and f1
  • No code changes to applications—just add a LAN ingress resource

    • -*Installing cert-manager*:
    +

    Installing cert-manager



    First, install cert-manager to handle certificate lifecycle management for LAN services. The installation is automated with a Justfile:

    @@ -5332,7 +5339,7 @@ http://www.gnu.org/software/src-highlite --> kubectl apply -f -
    -*Configuring FreeBSD relayd for LAN access*:
    +

    Configuring FreeBSD relayd for LAN access



    On both FreeBSD hosts (f0, f1), install and configure relayd for TCP forwarding:

    @@ -5361,7 +5368,7 @@ relay "lan_https" { }
    -Note: The IP addresses 192.168.1.120-122 are the LAN IPs of the k3s nodes (r0, r1, r2), not their WireGuard IPs. FreeBSD relayd requires PF (Packet Filter) to be enabled. Create a minimal /etc/pf.conf:
    +Note: The IP addresses 192.168.1.120-122 are the LAN IPs of the k3s nodes (r0, r1, r2), not their WireGuard IPs. FreeBSD relayd requires PF (Packet Filter) to be enabled. Create a minimal /etc/pf.conf:

     # Basic PF rules for relayd
@@ -5395,7 +5402,7 @@ _relayd  relayd   2903  12
 Repeat the same configuration on f1. Both hosts will run relayd listening on the CARP VIP, but only the CARP MASTER will respond to traffic. When failover occurs, the new MASTER takes over seamlessly.
    
 
    
-*Adding LAN ingress to services*:
    
+
    Adding LAN ingress to services

    
 
    
 To expose a service on the LAN, add a second Ingress resource to its Helm chart. Here's an example:
    
 
    
@@ -5450,7 +5457,7 @@ HTTP/2 302
 location: /app/

    -*Client-side DNS and CA setup*:
    +

    Client-side DNS and CA setup



    To access LAN services, clients need DNS entries and must trust the self-signed CA.

    @@ -5490,14 +5497,13 @@ $ sudo update-ca-trust
    After trusting the CA, browsers will accept the LAN certificates without warnings.

    -*Scaling to other services*:
    +

    Scaling to other services



    The same pattern can be applied to any service. To add LAN access:

    1. Copy the f3s-lan-tls secret to the service's namespace (if not already there)
    2. Add a LAN Ingress resource using the pattern above
    3. Configure DNS: 192.168.1.138 service.f3s.lan.foo.zone
    -4. Commit and push (ArgoCD will deploy automatically)

    No changes needed to:

    @@ -5506,7 +5512,7 @@ $ sudo update-ca-trust
  • cert-manager (wildcard cert covers all *.f3s.lan.foo.zone)
  • CARP configuration (VIP shared by all services)

    • -*TLS offloaders summary*:
    +

    TLS offloaders summary



    The f3s infrastructure now has three distinct TLS offloaders:

    -- cgit v1.2.3