Copyright © KC Green

Talos

Cilium BGP and a UniFi UDM-SE as the Lab iBGP Router

 infrastructure 

Advertise Kubernetes LoadBalancer IPs into the LAN with Cilium’s BGP control plane and the UDM gateway as peer.

You can get MetalLB-style service IPs without MetalLB. Cilium includes a BGP control plane that advertises LoadBalancer addresses on the LAN. The lab peers worker nodes with a UniFi UDM-SE as the default-gateway iBGP peer so phones, laptops, and the tailnet can reach Envoy Gateway VIPs without NodePorts.

Without BGP (or something like MetalLB), a LoadBalancer Service on bare metal often sits Pending forever. Advertising routes into the LAN gateway fixes that: the UDM learns /32 (or the pool) and forwards traffic to the node Cilium chose for the Service.

Lab GitOps: Talos, Flux, and a Monorepo

 infrastructure 

Why the lab pairs immutable Talos nodes with Flux CD — and which projects make that workable on ARM.

The lab is a Kubernetes testbed: try cluster layouts here before they go to production. After a short manual bootstrap, Flux keeps the cluster in sync with Git — the usual GitOps loop of declared state in version control and controllers that apply diffs.

Nodes run Talos Linux on Turing Pi RK1 boards. Images come from the Talos Image Factory (metal-arm64, sbc-rockchip / turingrk1). Talos keeps the node OS small and API-driven: you do not SSH in to patch packages. That pushes complexity into Kubernetes manifests, which fits a GitOps workflow.

Everything after the first bootstrap lives in one monorepo: cluster overlays, shared operators, Helm charts, and application kustomizations. Talos machine config (talconfig) is versioned there too, but applied with talosctl, not Flux. Drawing that line clearly avoids pretending the entire world is reconciled from Git when the hypervisor and disk layout are still operator steps.