<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Networking on Fuchsbau</title><link>https://this-is-fine.io/categories/networking/</link><description>Recent content in Networking on Fuchsbau</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Tue, 19 May 2026 15:26:18 +0200</lastBuildDate><atom:link href="https://this-is-fine.io/categories/networking/index.xml" rel="self" type="application/rss+xml"/><item><title>Den Tailscale-Operator für Headscale nachbauen: Das tailnet-gateway</title><link>https://this-is-fine.io/posts/20260519-headscale-tailnet-gateway/</link><pubDate>Tue, 19 May 2026 15:26:18 +0200</pubDate><guid>https://this-is-fine.io/posts/20260519-headscale-tailnet-gateway/</guid><description>&lt;p&gt;Mein Lab hängt an einem selbstgehosteten 

&lt;a href="https://headscale.net/" rel="external noopener" target="_blank"&gt;Headscale&lt;/a&gt;
 — einer quelloffenen Reimplementierung der Tailscale-Control-Plane. Das funktioniert wunderbar für Menschen und für die Talos-Knoten. Sobald ich aber wollte, dass auch die &lt;em&gt;Cluster-Dienste&lt;/em&gt; sauber im Tailnet auftauchen — die Kubernetes-API, die Talos-API, die clusterinterne Namensauflösung —, stieß ich auf eine Lücke: Der offizielle 

&lt;a href="https://tailscale.com/kb/1236/kubernetes-operator" rel="external noopener" target="_blank"&gt;Tailscale-Kubernetes-Operator&lt;/a&gt;
 ist für die Tailscale-SaaS gebaut, nicht für Headscale. Also habe ich die Teile, die ich tatsächlich brauche, selbst nachgebaut. Das Ergebnis ist ein einziges, gut lesbares StatefulSet: &lt;strong&gt;das tailnet-gateway&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Envoy Gateway: Ein Ingress, drei Welten und OIDC für alle</title><link>https://this-is-fine.io/posts/20260203-envoy-gateway-gateway-api/</link><pubDate>Tue, 03 Feb 2026 17:18:52 +0100</pubDate><guid>https://this-is-fine.io/posts/20260203-envoy-gateway-gateway-api/</guid><description>&lt;p&gt;Der Edge eines Clusters — die Stelle, an der externer Traffic auf die Workloads trifft — ist eine der Komponenten, die man besser einmal richtig baut. Bei mir hat dieser Punkt eine kleine Evolution hinter sich: von 

&lt;a href="https://traefik.io/" rel="external noopener" target="_blank"&gt;Traefik&lt;/a&gt;
 als klassischem Ingress-Controller über die Adoption der &lt;strong&gt;

&lt;a href="https://gateway-api.sigs.k8s.io/" rel="external noopener" target="_blank"&gt;Gateway-API&lt;/a&gt;
&lt;/strong&gt; bis hin zu &lt;strong&gt;

&lt;a href="https://gateway.envoyproxy.io/" rel="external noopener" target="_blank"&gt;Envoy Gateway&lt;/a&gt;
&lt;/strong&gt;, das diese API heute exklusiv umsetzt. Dieser Beitrag ist eine ausführliche Tour durch den Aufbau.&lt;/p&gt;</description></item></channel></rss>