<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Talos on johanneskueber.com</title><link>https://johanneskueber.com/tags/talos/</link><description>Recent content in Talos on johanneskueber.com</description><generator>Hugo</generator><language>en_US</language><lastBuildDate>Mon, 15 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://johanneskueber.com/tags/talos/index.xml" rel="self" type="application/rss+xml"/><item><title>Signed OCI Artifacts for Flux with Cosign and Gitea</title><link>https://johanneskueber.com/posts/2026-06-15-signed-oci-deployments/</link><pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-06-15-signed-oci-deployments/</guid><description>&lt;h1 id="signed-oci-artifacts-for-flux-with-cosign-and-gitea"&gt;Signed OCI Artifacts for Flux with Cosign and Gitea&lt;/h1&gt;
&lt;p&gt;Flux will happily pull a Git repository, run &lt;code&gt;kustomize build&lt;/code&gt; over a folder, and apply the result. I ran it that way for a long time and it works. What it does not give you is any statement about &lt;em&gt;what&lt;/em&gt; is being applied or &lt;em&gt;where it came from&lt;/em&gt;. The source of truth is a mutable branch - anyone who can write to that path, or anything that can, changes what lands in the cluster on the next reconcile. There is no integrity check sitting between &amp;ldquo;a commit exists&amp;rdquo; and &amp;ldquo;this is what is running in production.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Bare-Metal LoadBalancer Services on Talos with Cilium L2 Announcements</title><link>https://johanneskueber.com/posts/2026-06-01-cilium-l2-announcements/</link><pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-06-01-cilium-l2-announcements/</guid><description>&lt;p&gt;This article documents how to replace MetalLB with Cilium&amp;rsquo;s built-in L2 announcement feature, including the IPAM pool, the announcement policy, the supporting Cilium values, and what to verify on the wire.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-metallbs-role"&gt;1. MetalLB&amp;rsquo;s role&lt;/h2&gt;
&lt;p&gt;On a bare-metal cluster, a &lt;code&gt;Service&lt;/code&gt; of &lt;code&gt;type: LoadBalancer&lt;/code&gt; is meaningless until something assigns it an external IP and answers ARP for that IP on the local segment. The classic answer is MetalLB in L2 mode: a controller allocates an IP from a pool; a speaker DaemonSet replies to ARP requests, advertising via gratuitous ARP after leader election.&lt;/p&gt;</description></item><item><title>Per-PVC Encryption with Longhorn and CSI Secret Templates</title><link>https://johanneskueber.com/posts/2026-05-28-longhorn-per-pvc-encryption/</link><pubDate>Thu, 28 May 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-05-28-longhorn-per-pvc-encryption/</guid><description>&lt;p&gt;This article documents how to configure a Longhorn &lt;code&gt;StorageClass&lt;/code&gt; that encrypts every PVC with its own per-volume key, derived through CSI&amp;rsquo;s secret-template parameters, and how to provision the matching secrets so the keys are scoped to the application namespace.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-what-encryption-longhorn-actually-does"&gt;1. What encryption Longhorn actually does&lt;/h2&gt;
&lt;p&gt;Longhorn 1.4+ supports LUKS encryption at the block device layer. When a PVC&amp;rsquo;s StorageClass declares &lt;code&gt;encrypted: &amp;quot;true&amp;quot;&lt;/code&gt;, Longhorn calls &lt;code&gt;cryptsetup luksFormat&lt;/code&gt; on the underlying replica devices using a passphrase pulled from a Kubernetes Secret. The PVC is then exposed to the consuming Pod as an unencrypted filesystem — the kernel handles the encryption transparently through the device-mapper layer.&lt;/p&gt;</description></item><item><title>Intel iGPU passthrough with Proxmox and Talos</title><link>https://johanneskueber.com/posts/2025-10-11-proxmox-passthrough-talos/</link><pubDate>Sat, 11 Oct 2025 21:06:26 +0000</pubDate><guid>https://johanneskueber.com/posts/2025-10-11-proxmox-passthrough-talos/</guid><description>&lt;h2 id="igpu-passthrough-with-proxmox-and-talos"&gt;iGPU Passthrough with Proxmox and Talos&lt;/h2&gt;
&lt;p&gt;To use the GPU of the host system in K8s, it needs to be made aware of its existence. As I use VMs in Proxmox to run my Talos Cluster, there is an additional step to consider: passthrough of the hardware into the VM. The idea is the following:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Disable usage of GPU on the Proxmox Host - done via IOMMU and VFIO&lt;/li&gt;
&lt;li&gt;Passthrough of the GPU into a Talos Worker Node - done via hostpci&lt;/li&gt;
&lt;li&gt;Activation of GPU drivers in Talos - done via talhelper&lt;/li&gt;
&lt;li&gt;GPU management in the cluster - done via Intel GPU Plugin&lt;/li&gt;
&lt;li&gt;Usage of GPU in a deployment - by requesting the resource&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;There are quite some steps and all of them are specific to your environment. Different host system? Different steps. Different Cluster Software? You need to adept. Different GPU? You need other drivers and management. So please look out for the pitfalls and only copy and paste if you run proxmox with talos and have an Intel iGPU.&lt;/p&gt;</description></item><item><title>Use Longhorn with Talos 1.10 and userVolumes</title><link>https://johanneskueber.com/posts/2025-06-17-longhorn-uservolumes-talos/</link><pubDate>Tue, 17 Jun 2025 07:06:26 +0000</pubDate><guid>https://johanneskueber.com/posts/2025-06-17-longhorn-uservolumes-talos/</guid><description>&lt;p&gt;When building a cluster, especially in a homelab, local storage is needed for application data. Especially for databases fast read and write is required. Offloading the workload to a NAS most of the time is slower. The solution I use is to provision on-node storage with &lt;a href="https://longhorn.io/"&gt;Longhorn&lt;/a&gt;. Longhorn acts as a CSI and offers on-node storage, replication, backups and more.&lt;/p&gt;
&lt;p&gt;As I am currently building a Talos cluster I need to integrate the longhorn CSI into the setup. This is not as straigt forward as with K3s oder K8s, as Talos has tighter security constraints and also needs additional plugins to handle SCSI - the underlying file system protocol used by longhorn. On top I am using &lt;a href="https://budimanjojo.github.io/talhelper/latest/"&gt;Talhelper&lt;/a&gt; to allow a GitOps style usage of talosctl. The main advantage is the encryption of secrets used by talos config files with &lt;a href="https://github.com/getsops/sops"&gt;SOPS&lt;/a&gt; - something that I already use for Tofu and fluxCD.&lt;/p&gt;</description></item></channel></rss>