networking

Die Datenbank ist erreichbar. Jedenfalls vom Laptop. Aus dem Pod nicht. Der Tunnel steht, die Route ist angekündigt, der Proxy läuft, und trotzdem bleibt die Verbindung hängen. Irgendwo zwischen Kubernetes-Service, Headscale-Policy, Routenfreigabe und DNS fehlt ein Stück — nur gehört dieser Zusammenhang keinem einzelnen System.

Genau für diese Lücke entwickle ich tailnet-operator. Er macht aus Verbindungen zwischen Kubernetes und einem Headscale-Tailnet eigene Ressourcen: Ein Namespace bekommt einen stabilen Service für ein entferntes Ziel. Eine Anwendung bekommt einen privaten HTTPS-Eingang. Und die dazugehörigen Identitäten, Freigaben und Statusinformationen entstehen aus derselben Deklaration.

Nicht noch ein VPN. Sondern die fehlende Betriebslogik zwischen zwei bereits vorhandenen Welten.

Die letzten Tage im Lab waren ein Strukturschnitt. Lange gab es genau einen ernsthaften Cluster — hydra, bare-metal — und daneben einen Wegwerf-Test, von dem die ClusterMesh-Episode erzählte. Inzwischen ist daraus ein wiederholbares Muster geworden: ein Cluster pro Befehl, Anwendungen im cluster-scope, Flux-Tenants, eine aufgeräumte Tailnet-Domain — und eine Föderation, die bewusst kein Pod-Mesh ist. Dieser Beitrag fasst die Änderungen zusammen, spricht ehrlich über die Probleme dahinter und bewertet, wie produktionstauglich das Ganze wirklich ist.

Im vorigen Beitrag habe ich das tailnet-gateway gebaut — die kleine Brücke, die API, Talos und DNS eines Clusters ins Headscale-Tailnet bringt. Das hier ist die Fortsetzung. Mein Lab hat inzwischen einen zweiten Cluster (cosmos bei Hetzner, neben dem bare-metal hydra), und beide sollten föderiert werden: Pods und Services clusterübergreifend, mit Cilium ClusterMesh .

Die offizielle Anleitung sagt: clustermesh-apiserver per LoadBalancer exponieren, dafür sorgen, dass sich die Knoten beider Cluster direkt sehen, fertig. Genau das wollte ich nicht. Ich habe schon ein verschlüsseltes WireGuard-Fabric über Headscale — die Föderation soll da durch, nicht über öffentliche IPs. Diese eine Entscheidung hat mich durch ein halbes Dutzend Fallstricke geführt. Hier sind sie.

Im tailnet-gateway-Beitrag habe ich Headscale zur Kontrollebene des Labs gemacht: ein selbst gehosteter Coordination-Server, über den jeder Cluster ins Tailnet kommt. Die ClusterMesh-Episode hat denselben Strang weitergesponnen. Was beide stillschweigend voraussetzen: Es gibt genau eine Headscale-Instanz, auf hydra, und wenn die wegfällt, hat die Föderation kein Gehirn mehr. Genau diesen Single Point of Failure will ich auflösen — und der Weg dahin ist überraschend gestuft.

Mein Lab hängt an einem selbstgehosteten Headscale — 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 Cluster-Dienste sauber im Tailnet auftauchen — die Kubernetes-API, die Talos-API, die clusterinterne Namensauflösung —, stieß ich auf eine Lücke: Der offizielle Tailscale-Kubernetes-Operator 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: das tailnet-gateway.