<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on johanneskueber.com</title><link>https://johanneskueber.com/tags/kubernetes/</link><description>Recent content in Kubernetes on johanneskueber.com</description><generator>Hugo</generator><language>en_US</language><lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://johanneskueber.com/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><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>Signed Dependency Updates with Renovate and Gitea</title><link>https://johanneskueber.com/posts/2026-05-26-sign-renovate-commits/</link><pubDate>Tue, 26 May 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-05-26-sign-renovate-commits/</guid><description>&lt;p&gt;Keeping dependencies up to date is one of those chores that is easy to neglect and expensive to ignore. Renovate solves it nicely: it scans my repositories, opens pull requests for outdated dependencies, and - if I let it - merges them on its own. On a self-hosted Gitea instance with branch protection, however, there is a catch. If I require signed commits on my protected branches, an unsigned bot commit is simply rejected. So before automating anything, Renovate needs an identity and a signing key, and its commits need to show up as &lt;em&gt;Verified&lt;/em&gt;.&lt;/p&gt;</description></item><item><title>Running a rootless NetBird Routing Peer Inside Kubernetes</title><link>https://johanneskueber.com/posts/2026-05-25-netbird-routing-peer/</link><pubDate>Mon, 25 May 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-05-25-netbird-routing-peer/</guid><description>&lt;p&gt;This article documents how to run a NetBird client &lt;em&gt;inside&lt;/em&gt; a Kubernetes cluster as a &lt;strong&gt;routing peer&lt;/strong&gt; — rootless, with an in-memory state volume, a shell-based readiness probe, and dropped capabilities — so that remote mesh members can reach cluster-internal services over the encrypted overlay, without exposing kernel WireGuard and without making the cluster a peer of every workload.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-why-a-netbird-peer-in-the-cluster"&gt;1. Why a NetBird peer in the cluster&lt;/h2&gt;
&lt;p&gt;NetBird is a WireGuard-based identity mesh. Each peer holds keys, exchanges them via the management plane, and routes encrypted traffic to other peers. The default deployment runs the client on a host (Linux VM, MacBook, etc.) and uses the host&amp;rsquo;s kernel WireGuard.&lt;/p&gt;</description></item><item><title>Envoy Gateway Configuration to Reach SSL Labs A+</title><link>https://johanneskueber.com/posts/2026-05-14-envoy-gateway-ssllabs-a-plus/</link><pubDate>Thu, 14 May 2026 00:00:00 +0000</pubDate><guid>https://johanneskueber.com/posts/2026-05-14-envoy-gateway-ssllabs-a-plus/</guid><description>&lt;p&gt;This article documents the Envoy Gateway configuration required to achieve an A+ rating on Qualys SSL Labs, with the rationale for each setting.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-tls-security-background"&gt;1. TLS security background&lt;/h2&gt;
&lt;p&gt;Before any application data flows over &lt;code&gt;https://&lt;/code&gt;, the TLS session completes two steps:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Authentication.&lt;/strong&gt; The server presents an X.509 certificate signed by a trusted Certificate Authority.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Key agreement and encryption.&lt;/strong&gt; Client and server negotiate a session key via a cipher suite (key exchange, signature, bulk cipher, MAC) and encrypt the channel.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Weaknesses in this chain enable specific attack classes:&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><item><title>Enable hardware acceleration for Jellyfin in Kubernetes - AMD Edition</title><link>https://johanneskueber.com/posts/2024-06-24-hardware-acceleration-kubernetes-jellyfin/</link><pubDate>Mon, 24 Jun 2024 07:06:26 +0000</pubDate><guid>https://johanneskueber.com/posts/2024-06-24-hardware-acceleration-kubernetes-jellyfin/</guid><description>&lt;p&gt;&lt;a href="https://jellyfin.org/"&gt;Jellyfin&lt;/a&gt; is an open-source media server software that allows users to manage and stream their personal collection of movies, TV shows, music, and other media files. It is designed as an alternative to proprietary media server solutions like Plex and Emby, offering similar functionality but without any licensing costs or restrictions.&lt;/p&gt;
&lt;p&gt;Jellyfin is running in my bare-metal kubernetes cluster. However, running the container without additional configuraion only gives Jellyfin access to the CPU for decoding video streams. If a GPU is available it would be better to use the GPU as it - most of the time - also has hardware acceleration for well-known codecs and in addition it takes some work off the CPU. In my case, the Athlon 3000G has an on-board Vega 3 graphics chip. Now the only thing left to do is to give Jellyfin access to the GPU.&lt;/p&gt;</description></item><item><title>Migrating data between baserow instances</title><link>https://johanneskueber.com/posts/2024-06-19-migrating-baserow-data-between-instances/</link><pubDate>Wed, 19 Jun 2024 07:06:26 +0000</pubDate><guid>https://johanneskueber.com/posts/2024-06-19-migrating-baserow-data-between-instances/</guid><description>&lt;p&gt;&lt;a href="https://baserow.io/"&gt;Baserow&lt;/a&gt; is an open-source alternative to tools like Airtable and Google Sheets. It allows users to create databases and manage data in a user-friendly, spreadsheet-like interface. With Baserow, you can store, share, and collaborate on data with your team, all while maintaining full control over your data as it&amp;rsquo;s self-hosted. It offers features like row-level permissions, different field types, views (like table, gallery, kanban), and more. It also provides APIs for developers to build custom apps or integrations.&lt;/p&gt;</description></item></channel></rss>