Cilium ClusterMesh durchs Tailnet — Föderation ohne öffentliche IPs

Zwei Talos-Cluster mit Cilium ClusterMesh verbinden, aber alles über das bestehende Headscale-Tailnet statt über LoadBalancer und öffentliche IPs. Eine Sammlung der Fallstricke — und der Erkenntnis, die die Datenebene am Ende rettete.

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.

Von Makefiles zu task: Das Cluster über Anweisungen bedienen

Warum ich die operativen Anweisungen meines Labs von Makefiles auf go-task migriert habe — mit Namespaces, Preconditions, Prompts und einem Überblick, was sich damit alles steuern lässt

Ein Follow-up zum GitOps-Aufbau meines Labs: Wenn das Repository den Zustand beschreibt, brauche ich trotzdem eine Handvoll Anweisungen, um den Cluster zu bedienen — bootstrappen, Secrets rotieren, Backups zurückspielen, Zertifikate erneuern. Lange lebten diese Anweisungen in Makefiles. Heute steckt jede davon in einem go-task -Taskfile, und der Umstieg war eine der besseren kleinen Entscheidungen.

Matrix betreiben: Wenn die E2EE-Verschlüsselung zum Betriebsproblem wird

Ein Synapse-Homeserver im Lab, der schmerzhafte Sonderfall Ende-zu-Ende-Verschlüsselung für meinen Bot ZeroClaw — und das Tooling, das ich bauen musste, um ihn beherrschbar zu machen

Ich betreibe einen eigenen Matrix -Homeserver — Synapse , erreichbar unter matrix.this-is-fine.social. Der laufende Betrieb ist erfreulich langweilig; ein Aspekt aber hat mich mehr Nerven gekostet als alles andere zusammen: die Ende-zu-Ende-Verschlüsselung, und zwar ausgerechnet für meinen automatisierten Teilnehmer, den Bot ZeroClaw. Dieser Beitrag handelt von diesem Schmerz — und dem Tooling, das ich bauen musste, um ihn zu zähmen.

Radicle: Eine Forge, die niemandem gehört

Was eine peer-to-peer-Git-Forge für die Open-Source-Welt bedeutet — und warum ich gerade all meine Repos von SourceHut zu Radicle umziehe

Git ist von Haus aus dezentral — aber die Art, wie wir damit zusammenarbeiten, ist es längst nicht. Pull Requests, Issues, Reviews: All das lebt auf zentralen Plattformen, die das Protokoll selbst gar nicht braucht. Radicle holt diese Kollaborationsschicht zurück ins dezentrale Modell, und genau deshalb ziehe ich gerade nicht nur mein Lab, sondern alle meine Repos dorthin um — und das sind einige, überwiegend die Quellen meiner Container-Images.

ZeroClaw: Ein KI-Agent als Operator im Lab

Vom Vorgänger OpenClaw zum schlankeren, sichereren ZeroClaw — wie ein KI-Agent meine Cluster überwacht, über Matrix spricht und Änderungen als Radicle-Patches vorschlägt

In meinem Lab läuft ein KI-Agent mit, der die Cluster im Auge behält, mir auf Matrix Bescheid gibt und Reparaturen nicht selbst durchdrückt, sondern als Patch vorschlägt. Er heißt ZeroClaw — im Chat nur Claw — und ist der schlankere, vorsichtigere Nachfolger meines früheren Agenten OpenClaw. Dieser Beitrag zeigt, wie er integriert ist, über welche Kanäle er kommuniziert und wie der Weg von einer Idee bis zum gemergten Patch aussieht.