#operator

tailnet-operator: Verbindungen deklarieren statt Proxys verkabeln

Permalink 12 min read Published:
 infrastructure  networking  #tailnet-operator #headscale #tailscale #kubernetes #operator #gitops #networking #tls #golang
Kubernetes und Headscale sprechen nicht automatisch dieselbe Sprache. Mein tailnet-operator verbindet beide Welten: Services für entfernte Ziele, private HTTPS-Eingänge, abgeleitete Zugriffsregeln und Statusmeldungen, die mehr sagen als ‚Pod läuft‘. Eine Vorstellung anhand des realen Lab-Einsatzes.

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.

Tor als CRD: ein eigener Operator statt Sidecar-Bastelei

Permalink 10 min read Modified: (UPDATED)
 infrastructure  howto  #tor #kubernetes #operator #rust #kube-rs #onion-service #obfs4 #hidden-service #gitops
Warum ich den inoffiziellen tor-controller durch einen eigenen, in Rust geschriebenen Operator ersetzt habe — ein gemeinsamer Tor-Daemon pro Namespace, Onion-Services und Onion-Proxies dynamisch über den Control-Port, plus kuratierte obfs4-Bridges

Tor-Konnektivität im Cluster hatte ich bisher zusammengesteckt: pro Pod ein client-only tor plus ein oder zwei socat-Sidecars, die lokale TCP-Ports in Onion-Services übersetzten — genau das Setup, das ich im IRC-Bouncer-Beitrag beschrieben habe. Das funktioniert, skaliert aber nicht als Muster: Jeder Workload, der eine .onion erreichen oder selbst eine anbieten wollte, brachte seinen eigenen Tor-Prozess und seine eigene Klebeschicht mit. Also habe ich das Ganze zu dem gemacht, was es im Lab sein sollte: einer Custom Resource. tor-operator ist ein eigener, in Rust geschriebener Kubernetes-Operator, der Tor-Konnektivität in beide Richtungen als CRD anbietet.

Eine Postgres-Plattform statt zehn Datenbanken — CloudNativePG im Lab

Permalink 5 min read Published:
 infrastructure  databases  #cloudnativepg #cnpg #postgresql #kubernetes #ha #backup #volumesnapshot #operator #flux
Synapse, Mastodon, Harbor, Pocket-ID, Headscale: fast jeder zustandsbehaftete Dienst im Lab will Postgres. Früher hieß das zehn handgepflegte Datenbanken. Heute ist es ein Operator und pro Dienst ein dreizeiliges Cluster-Manifest — mit synchroner Replikation über drei Instanzen, VolumeSnapshot-Backups, automatischem Failover und Prometheus-Metriken out of the box. Wie CloudNativePG aus einer Bürde eine Plattform macht.

Wenn ich die zustandsbehafteten Dienste in meinem Lab durchgehe, fällt ein Muster auf: Synapse , Mastodon , Harbor, Pocket-ID , Headscale — sie alle wollen Postgres. Früher bedeutete das eine Handvoll handgepflegter Datenbanken, jede mit eigener Backup-Logik, eigenem Failover-Plan (also keinem) und eigener Überwachung (auch keiner). Heute ist Postgres in meinem Lab eine Plattform: ein Operator, und pro Dienst ein winziges deklaratives Cluster-Manifest. Das ist CloudNativePG .