https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/tags/kubernetes/ Recent content in Kubernetes on Rouke Broersma Hugo -- gohugo.io rouke@broersma.dev (Rouke Broersma) rouke@broersma.dev (Rouke Broersma) Sat, 29 Mar 2025 16:38:34 +0000 https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/talos-linux-and-dynamic-resource-allocation-beta/ Sat, 29 Mar 2025 16:38:34 +0000 rouke@broersma.dev (Rouke Broersma) https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/talos-linux-and-dynamic-resource-allocation-beta/ I upgraded my Kubernetes cluster to 1.32 recently and the changelog mentioned that Dynamic Resource Allocation (DRA) had been graduated to Beta. I had been using the Intel GPU Device Plugin to schedule pods with Hardware Device requirements until now. This seemed like a good opportunity to try out and switch to DRA. Surprisingly, this was fairly simple! I initially ran into some speedbumps but now that I figured it out it’s fairly straightforward. https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/approve-private-endpoint-connections/ Thu, 23 Feb 2023 00:00:00 +0000 rouke@broersma.dev (Rouke Broersma) https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/approve-private-endpoint-connections/ Managing private endpoint connections - especially across Azure AD tenants - can be a chore. In many cases you will have to do this manually and often you will need elevated permissions. Though usually your deployment pipeline already has sufficient permissions on the resource to approve the endpoint connection, so it would be much more convenient if we could make the approval a part of our desired state config. https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/azure-aks-private-clusters/ Mon, 20 Feb 2023 20:39:47 +0000 rouke@broersma.dev (Rouke Broersma) https://67ea45403ad50a0008fd0d16--broersmadev.netlify.app/azure-aks-private-clusters/ When using Kubernetes it is considered good practice to limit API server access as much as possible. However the default configuration on cloud providers exposes the API server on the public internet. This is fine when you’re giving it a try but once you start using Kubernetes more seriously you will probably want to start locking down access.