LoadBalancer-IPs auf Bare-Metal: Cilium BGP gegen die UDM-SE

Cilium als kube-proxy-freie CNI und seine BGP-Control-Plane, die Service-IPs per eBGP an eine Ubiquiti UDM-SE annonciert

In der Cloud ist ein Service vom Typ LoadBalancer ein gelöstes Problem — der Provider zaubert eine IP herbei. Auf Bare-Metal ist genau das die Lücke: Wer vergibt die IP, und wer sorgt dafür, dass das Netzwerk sie auch findet? In meinem Lab erledigt das Cilium — als CNI und gleichzeitig als BGP-Sprecher, der die Service-IPs an meine Ubiquiti UDM-SE annonciert.

Cilium als CNI

Cilium ist auf jedem Cluster die einzige CNI, installiert direkt über die Talos-Maschinenkonfiguration. Es ersetzt kube-proxy vollständig (kubeProxyReplacement: true) und bewegt das gesamte Service- und NetworkPolicy-Handling per eBPF in den Kernel. Pod-IPAM läuft im kubernetes-Modus; die Verschlüsselung des Pod-Traffics ist bewusst aus, weil die clusterübergreifenden Pfade ohnehin über das WireGuard des Headscale-Tailnets laufen.

Spannend wird es beim Übergang vom Cluster ins LAN.

Ein Lab, das sich selbst beschreibt: GitOps mit Flux

Wie aus imperativen Skripten ein deklaratives Monorepo wurde, das Soll- und Ist-Zustand zugleich abbildet — und wie Flux die Ressourcen im Cluster verdrahtet

Die Hardware ist nur das Fundament. Was mein Lab eigentlich ausmacht, ist ein einziges Git-Repository, das den kompletten Cluster beschreibt — und zwar nicht als Dokumentation, sondern als verbindliche Quelle der Wahrheit. Dieser Beitrag ist die kurze Geschichte, wie es dazu kam, und wie die Teile heute zusammenspielen.

IRC, das nie offline geht: ZNC über Tor und ein eigener InspIRCd

Ein persistenter IRC-Bouncer auf Kubernetes, der seine Upstream-Netze als Onion-Services über Tor erreicht — plus ein interner IRCd und ein nostalgischer Blick auf BitlBee

IRC ist tot, lang lebe IRC. Während der Rest der Welt durch Messenger-Silos zieht, hänge ich nach wie vor gern in ein paar IRC-Kanälen ab — und damit mir dabei keine Zeile entgeht, betreibe ich einen Bouncer. Bei mir ist das ZNC , läuft auf Kubernetes und erreicht seine Upstream-Netze nicht direkt, sondern als Onion-Services über Tor.

Eine eigene Mastodon-Instanz im Fediverse

Warum dezentrale soziale Netze wichtig sind — und wie meine Mastodon-Instanz auf Kubernetes aus Web, Streaming, PostgreSQL, Dragonfly und Object-Storage zusammengesetzt ist

Soziale Netze müssen niemandem gehören. Genau das ist der Reiz des Fediverse: ein Verbund unabhängiger Server, die über ein gemeinsames Protokoll miteinander reden, statt sich einer zentralen Plattform unterzuordnen. Auf meinem Lab betreibe ich deshalb unter this-is-fine.social eine eigene Mastodon -Instanz. Dieser Beitrag erklärt, warum mir das wichtig ist — und wie der Stack auf Kubernetes konkret zusammengesetzt ist.

Die Hardware-Basis meines Labs: Turing Pi, RK1 und Talos

Vom Kickstarter-Board mit vier Raspberry-Pi-Modulen zum RK1-Cluster mit NVMe — und warum am Ende Talos Linux darauf läuft

Jedes Lab braucht ein Stück Blech, auf dem es steht. Bei mir ist das ein Turing Pi -Board — ein Mini-ITX-Träger für vier Compute-Module, den ich seinerzeit in der Kickstarter-Kampagne mitfinanziert habe. Die Idee, einen kleinen, lautlosen und stromsparenden Cluster aus austauschbaren Knoten in einem einzigen Gehäuse zu betreiben, hat mich sofort überzeugt. Diese Geschichte handelt davon, wie aus der ersten, etwas naiven Bestückung über ein paar Umwege die heutige Basis von hydra wurde.