#kubernetes

Restore als ein Kommando — die backup-Task-Kategorie

Ein VolSync-Restore ist eine sechsstufige Choreografie aus Flux-suspend, PVC-wipe und restic-restore. Wie das go-task-Setup im Lab daraus ein einziges, idempotentes Kommando macht — inklusive des Pod-Security-Tricks, der den wipe-Job überhaupt erst durchlässt.

Ein Restore ist der eine Moment, in dem man garantiert unter Stress steht: irgendwas ist kaputt, und ausgerechnet jetzt soll man sich die Reihenfolge aus Flux-suspend, PVC-leeren, restic restore und Flux-resume fehlerfrei aus dem Kopf klicken. Genau diese Reihenfolge gehört nicht in den Kopf, sondern in Code. Im go-task-Setup des Labs übernimmt das die backup-Kategorie — ein dünner Wrapper um VolSync und restic , der aus dem VolSync-Aufbau ein paar einprägsame Kommandos macht.

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.

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.

Den Tailscale-Operator für Headscale nachbauen: Das tailnet-gateway

Warum der offizielle Tailscale-Kubernetes-Operator nicht zu meinem selbstgehosteten Headscale passt — und wie ich die Teile, die ich brauche, als ein einziges StatefulSet nachgebaut habe

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.