<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Projects on GeekyRyan</title><link>https://rnemeth90.github.io/categories/projects/</link><description>Recent content in Projects on GeekyRyan</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 17 Aug 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://rnemeth90.github.io/categories/projects/index.xml" rel="self" type="application/rss+xml"/><item><title>DnsPinger: A Small .NET Tool for Diagnosing DNS Issues in Kubernetes</title><link>https://rnemeth90.github.io/projects/2023-08-17-dnspinger/</link><pubDate>Mon, 17 Aug 2026 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-08-17-dnspinger/</guid><description>&lt;p&gt;DNS problems in Kubernetes are some of the most frustrating issues to chase down. They&amp;rsquo;re often intermittent, they can differ by node, by node pool, by which resolver actually answered the query, and the standard toolbox (&lt;code&gt;nslookup&lt;/code&gt;/&lt;code&gt;dig&lt;/code&gt; run once by hand) doesn&amp;rsquo;t tell you much about a problem that only shows up 1% of the time or only on certain nodes. I got tired of manually reproducing DNS flakiness during incidents, so I wrote &lt;strong&gt;DnsPinger&lt;/strong&gt; — a small, purpose-built .NET console application that continuously exercises DNS resolution from inside the cluster and reports what it finds.&lt;/p&gt;</description></item><item><title>Migrating AKS Workloads to Azure Workload Identity</title><link>https://rnemeth90.github.io/projects/2023-06-13-aks-workload-identity-migration/</link><pubDate>Tue, 13 Jun 2023 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-06-13-aks-workload-identity-migration/</guid><description>&lt;p&gt;For a long time, the standard way for a pod in AKS to authenticate to Azure resources (Key Vault, databases, service bus, etc.) was some flavor of managed identity binding via a sidecar (AAD Pod Identity), or worse, credentials baked into a secret. Azure Workload Identity is the modern replacement: it federates a Kubernetes service account with an Azure AD identity using OIDC, with no secrets to manage or rotate.&lt;/p&gt;</description></item><item><title>Locking Down AKS Access with Azure RBAC and Privileged Identity Management</title><link>https://rnemeth90.github.io/projects/2023-05-01-aks-rbac-and-pim/</link><pubDate>Mon, 01 May 2023 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-05-01-aks-rbac-and-pim/</guid><description>&lt;p&gt;Kubernetes&amp;rsquo; built-in RBAC is powerful, but managing it purely inside the cluster (via kubeconfigs and static role bindings) doesn&amp;rsquo;t integrate well with how most organizations manage identity and access at the directory level. Azure RBAC integration for AKS lets you manage cluster access using Azure AD groups and role assignments, which is a much better fit for how access reviews and least-privilege policies actually get enforced.&lt;/p&gt;&#10;&lt;p&gt;This project deployed Azure RBAC to our AKS clusters so that cluster access is controlled the same way as the rest of our Azure resources, and paired it with Privileged Identity Management (PIM) so that elevated cluster permissions are just-in-time and time-bound rather than standing access.&lt;/p&gt;</description></item><item><title>Diagnosing and Safely Re-enabling AKS Automatic Node Image Updates</title><link>https://rnemeth90.github.io/projects/2023-03-21-aks-automatic-node-image-updates/</link><pubDate>Tue, 21 Mar 2023 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-03-21-aks-automatic-node-image-updates/</guid><description>&lt;p&gt;AKS has a feature that automatically applies the latest node image to your node pools on a schedule. It&amp;rsquo;s a great way to stay current on OS-level patches without manual intervention - until it causes a service degradation in prod.&lt;/p&gt;&#10;&lt;p&gt;After an automatic node image rollout caused instability in one of our environments, we disabled the feature while we investigated with Microsoft support. No definitive root cause was found, but the support engagement did produce some useful recommendations around additional node-level logging to capture if the issue recurred.&lt;/p&gt;</description></item><item><title>Rolling Out New AKS Clusters to Retire Duplicate Infrastructure</title><link>https://rnemeth90.github.io/projects/2023-03-21-rolling-out-new-aks-clusters/</link><pubDate>Tue, 21 Mar 2023 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-03-21-rolling-out-new-aks-clusters/</guid><description>&lt;p&gt;Over time, infrastructure accumulates cruft - clusters stood up for a specific purpose that never got cleaned up, duplicate environments left over from a migration, that sort of thing. This project stood up a new generation of AKS clusters specifically so we could decommission an older, duplicate set of infrastructure that was quietly costing money every month.&lt;/p&gt;&#10;&lt;p&gt;The approach was straightforward: build the new clusters alongside the old ones, migrate workloads over, validate, and then tear down the legacy infrastructure. Running both environments in parallel for a short overlap period had a real (if temporary) cost - a few thousand dollars over a couple of months - but it bought us a safe cutover with a rollback path, which was worth it compared to the ongoing cost of carrying duplicate infrastructure indefinitely.&lt;/p&gt;</description></item><item><title>Upgrading AKS Clusters to a Supported Kubernetes Version</title><link>https://rnemeth90.github.io/projects/2022-02-23-aks-cluster-version-upgrade/</link><pubDate>Wed, 23 Feb 2022 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2022-02-23-aks-cluster-version-upgrade/</guid><description>&lt;p&gt;One of the recurring themes of running Kubernetes in production is that clusters age out of support fairly quickly. Azure Kubernetes Service (AKS), at the time of this writing, only supports a rolling window of Kubernetes minor versions, so falling behind means losing patch support and eventually being forced into an emergency upgrade.&lt;/p&gt;&#10;&lt;p&gt;This project was a routine but important control-plane and node-pool upgrade across our AKS clusters to bring them onto a supported Kubernetes version (1.21.x at the time). The work itself followed a pattern we&amp;rsquo;ve refined over several of these upgrades:&lt;/p&gt;</description></item></channel></rss>