#kubernetes

Ob ein einzelner Dienst im LAN oder ein komplettes Subnetz an einem anderen Standort: Kubernetes endet nicht an der Clustergrenze. Anwendungen brauchen Zugriff auf bestehende Systeme, während Dienste im Cluster für berechtigte Nutzer außerhalb erreichbar sein sollen. Dafür muss weder alles nach Kubernetes umziehen noch öffentlich im Internet stehen.

Genau dafür entwickle ich Tsunaro. Der Open-Source-Operator verbindet Kubernetes mit einem eigenen Headscale-Tailnet. Headscale ist ein Open-Source-Control-Server für Tailscale, den ihr selbst hosten könnt, auch vollständig on-premises. Damit liegt die zentrale Verwaltung des privaten Netzes in eurer Hand. Statt für jede Anwendung Proxys, DNS-Einträge und Zugriffsregeln einzeln zu pflegen, beschreibt ihr die gewünschte Verbindung. Tsunaro übernimmt die wiederkehrende Arbeit und läuft damit bereits seit Längerem in mehreren Umgebungen produktiv.

Ein Storage-Problem löst mehrere Volume-Alerts aus, betroffene Pods melden Fehler, und schließlich fällt ein Dienst aus, dem seine Abhängigkeit fehlt. Das Monitoring arbeitet dabei korrekt. Aus den einzelnen Meldungen ergibt sich aber noch keine Antwort auf die wichtigste Frage: Was ist passiert, und was muss ich jetzt entscheiden?

Dabei soll ZeroClaw in meinem Lab helfen. Als Alert-Gate und lesender Triage-Assistent fragt der Agent den Clusterzustand ab und soll zusammengehörige Symptome einordnen. Bekannte Meldungen soll er zurückhalten, neue relevante Vorfälle verständlich zusammenfassen. Deployments selbst zu reparieren gehört nicht zu seinem Auftrag.

Für diesen Einsatz sind die Grenzen ebenso wichtig wie die Diagnose: Welche Daten darf der Agent lesen, welche Änderungen sind ihm erlaubt? Und wer bemerkt es, wenn ausgerechnet der Assistent schweigt?

Vom Laptop ist die Datenbank erreichbar, aus dem Pod bleibt die Verbindung hängen. Dabei steht der Tunnel, die Route ist angekündigt und der Proxy läuft. Die Ursache kann im Zusammenspiel von Kubernetes-Service, Headscale-Policy, Routenfreigabe und DNS liegen. Keines dieser Systeme prüft jedoch allein, ob alle Voraussetzungen für die Verbindung erfüllt sind.

Für diese Lücke entwickle ich tailnet-operator. Er bildet Verbindungen zwischen Kubernetes und einem Headscale-Tailnet als eigene Ressourcen ab. Damit bekommt ein Namespace einen stabilen Service für ein entferntes Ziel oder eine Anwendung einen privaten HTTPS-Eingang. Die zugehörigen Identitäten, Freigaben und Statusinformationen entstehen aus derselben Deklaration.

Der Operator nutzt die vorhandene VPN-Infrastruktur und übernimmt die Betriebslogik, die bisher zwischen Kubernetes und Headscale von Hand gepflegt werden musste.

Nach dem Scannen liegt die Rechnung als scan_0042.pdf in einem Verzeichnis. Sie lässt sich öffnen, aber ohne brauchbaren Namen und Metadaten später nur schwer wiederfinden. Bei E-Mails ist es ähnlich: Der Anhang ist vorhanden, sein Zusammenhang steckt jedoch im Postfach. Ob beides zuverlässig gesichert ist, muss zusätzlich geklärt werden.

Paperless-ngx soll in meinem Lab Dokumente aufnehmen, durchsuchbar machen und mit brauchbaren Metadaten versehen. Nach dem ersten erfolgreichen Upload ging es vor allem darum, den gesamten Ablauf verlässlich zu gestalten: Wie landet ein Scan vollständig im Archiv? Was darf ein Sprachmodell entscheiden? Und wie stelle ich Dateien und Datenbank so wieder her, dass sie zusammenpassen?

Seit dem letzten größeren Lab-Rückblick hat sich vor allem der Betrieb weiterentwickelt. Damals waren bessere Beobachtbarkeit, mehrschichtige Backups und weniger Handarbeit an den Übergängen zwischen Systemen noch offene Aufgaben. Inzwischen erfasst die Logsammlung auch die Control Plane, Backups verlassen die Ausfalldomäne des Clusters, und externe Checks überwachen das Monitoring selbst.

Daneben kamen neue Dienste hinzu. In diesem Rückblick geht es aber vor allem um die Änderungen, die das Lab im Alltag belastbarer machen. Grundlage ist die öffentliche Lab-Konfiguration Anfang Oktober 2026.