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.

Wenn der erste Build durchläuft, funktioniert der grundlegende Ablauf einer eigenen CI. Für den verlässlichen Betrieb bleiben jedoch Fragen offen, die eine gehostete Forge oft bereits im Produkt beantwortet. Dazu gehören Ausführungsrechte, die Zuordnung von Images zu Commits und die Prüfung beider Architekturen. Dazu kommt die Freigabe eines Releases, bei der Git-Tag, Registry-Artefakt und Radicle-Veröffentlichung zusammenpassen müssen, obwohl sie getrennt entstehen.

Mein erster CI-Broker-Beitrag beschrieb die Probleme beim Aufbau und die Lösungen, die daraus entstanden sind. Diese Fortsetzung führt schrittweise durch die Einrichtung und richtet sich an Menschen, die Radicle bereits verwenden und ihre eigene CI betreiben möchten. Der Broker ist inzwischen bei v1.5.0 angekommen. Er unterstützt die gemeinsame Veröffentlichung und Signierung von Images und Charts, bringt Werkzeuge für SBOMs und Schwachstellenscans mit und verarbeitet Release-Ereignisse zuverlässiger.

Dafür muss niemand mein komplettes Lab nachbauen. Entscheidend ist der Weg vom replizierten Commit bis zu einem Artefakt, dessen Herkunft und Prüfergebnisse auch andere nachvollziehen können.

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?