<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <docs>https://blogs.law.harvard.edu/tech/rss</docs>
    <title>Talos on Fuchsbau</title>
    <link>https://this-is-fine.io/tags/talos/</link>
    <description>Recent content in Talos on Fuchsbau</description>
    <image>
      <title>Talos on Fuchsbau</title>
      <link>https://this-is-fine.io/tags/talos/</link>
      <url>https://source.unsplash.com/2000x1322/?fox</url>
    </image>
    <ttl>1440</ttl>
    <generator>Hugo 0.125.4</generator>
    <language>de-DE</language>
    <lastBuildDate>Wed, 20 May 2026 22:26:12 UT</lastBuildDate>
    <atom:link href="https://this-is-fine.io/tags/talos/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cilium BGP and a UniFi UDM-SE as the Lab iBGP Router</title>
      <link>https://this-is-fine.io/posts/20251122-cilium-bgp-unifi-udm/</link>
      <pubDate>Sat, 22 Nov 2025 09:00:00 UT</pubDate>
      <dc:creator>ff0x</dc:creator>
      <guid>https://this-is-fine.io/posts/20251122-cilium-bgp-unifi-udm/</guid>
      <description>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.
</description>
      <category domain="https://this-is-fine.io/categories/infrastructure">Infrastructure</category>
      <content:encoded><![CDATA[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.
Topology LAN: UniFi UDM-SE (iBGP peer, ASN 65535) iBGP to Talos workers (ASN 64512, bgp-policy=worker) workers advertise LoadBalancer pool 10.103.0.0/28 .0.1 external gateway, .0.2 internal, .0.3 tailnet, ... Controllers are not BGP speakers (bgp-policy: controller); only workers export routes. That matches how the lab uses workers for ingress dataplane traffic while keeping the control plane off the BGP session.
Cilium objects (upstream docs) Resource Role CiliumBGPClusterConfig Local ASN, node selectors, peer discovery CiliumBGPPeerConfig Neighbour capabilities CiliumBGPAdvertisement Export LoadBalancerIP services CiliumLoadBalancerIPPool Service IP CIDR Helm enables bgpControlPlane and l2announcements; GitOps overlays add the CRs and substitute ${CLUSTER_LOAD_BALANCER_CIDR} per cluster.
UniFi side On the UDM-SE, configure BGP to accept ASN 64512 and install learned routes (often /32 or the advertised /28 — steps depend on firmware; see UniFi’s BGP documentation). Cilium auto-discovers the peer via each worker’s default gateway, using CLUSTER_BGP_ROUTER_ADDR in cluster config instead of a static neighbour list per node.
Why it matters in this lab Envoy gateways keep stable .0.1 / .0.2 / .0.3 addresses from one pool. Headscale advertises the same /28 to the tailnet (tag:fabric) so mesh clients reach those VIPs. ARM64 Talos nodes on Turing Pi speak BGP like any other Linux host. Related Envoy gateways — services on those IPs Tailscale mesh — tailnet route approval Lab GitOps — Cilium in the common layer More: Cilium BGP v2, Talos with Cilium.
]]></content:encoded>
    </item>
    <item>
      <title>Lab GitOps: Talos, Flux, and a Monorepo</title>
      <link>https://this-is-fine.io/posts/20251120-lab-gitops-flux-talos/</link>
      <pubDate>Thu, 20 Nov 2025 08:00:00 UT</pubDate>
      <dc:creator>ff0x</dc:creator>
      <guid>https://this-is-fine.io/posts/20251120-lab-gitops-flux-talos/</guid>
      <description>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.
</description>
      <category domain="https://this-is-fine.io/categories/infrastructure">Infrastructure</category>
      <content:encoded><![CDATA[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.
Stack (what each piece teaches) Piece Learn more Talos API-driven, immutable nodes — no SSH shell on hosts Flux GitRepository, Kustomization, HelmRelease Kustomize &#43; Helm Overlays vs charts — choose per app SOPS &#43; AGE Encrypted secrets in Git; decrypted at reconcile Vault &#43; External Secrets Long-lived credentials outside plain Git Cilium CNI; BGP can advertise service LoadBalancer ranges Gateway API &#43; Envoy Gateway HTTP and TCP ingress cert-manager ACME and in-cluster CAs Rook-Ceph Block, filesystem, and S3-style storage Renovate Automated bumps for image and chart pins Bootstrap, then GitOps flash Talos (RK1) -&amp;gt; talosctl bootstrap -&amp;gt; flux bootstrap Git becomes the source of truth One monorepo holds shared common/ operators and per-cluster overlays. The GitRepository uses an ignore block so Flux does not clone agent code, docs, or unrelated trees on every reconcile. That keeps sync intervals reasonable on modest hardware.
How a change rolls out Git branch (main) -&amp;gt; GitRepository (poll) -&amp;gt; common layer (Flux, Cilium, cert-manager, ...) -&amp;gt; repo definitions (Helm/OCI) -&amp;gt; app overlays (your workloads) -&amp;gt; HelmRelease, HTTPRoute, PVC, ExternalSecret, ... dependsOn orders that graph (storage before apps, for example). postBuild substitution reads common-config and fills hostnames — this-is-fine.io, this-is-fine.social, this-is-fine.internal, tif.internal — so the same manifests work on every cluster without per-site forks.
Bootstrap secrets use SOPS; runtime passwords and tokens live in Vault and sync through External Secrets. The split mirrors how often values change: bootstrap keys rotate rarely; database passwords and API tokens churn more often and are easier to audit in Vault.
Renovate watches the same repo and opens bump PRs for container images, Helm charts, and Talos or Flux pins. That closes the loop so the lab does not silently fall behind upstream.
DNS zones (quick map) this-is-fine.io public internet (ACME, external gateway) this-is-fine.social fediverse this-is-fine.internal lab UIs (internal gateway, Vault PKI) tif.internal Headscale tailnet (MagicDNS) Takeaway Talos limits the OS problem; Flux limits the “what is actually deployed?” problem. Together they give a repeatable lab: flash boards, bootstrap once per cluster, then iterate by merge request like any other software project.
More on this setup: ZeroClaw, Envoy Gateway, Cilium BGP, Zot, Pocket ID, backups, tailnet, image signing.
]]></content:encoded>
    </item>
  </channel>
</rss>
