top of page

From Cluster Chaos to Clarity: My Wild Ride Upgrading Azure AKS

  • April Rieger
  • Sep 5
  • 3 min read

When a "quick upgrade" becomes a masterclass in cloud resilience

An image of a roller coaster with text overlay "From Cluster Chaos to Clarity; My Wild Ride Upgrading Azure AKS",  with the Kubernetes logo, the Microsoft Azure AKS logo, and the Notch8 logo.
An image of a roller coaster with text overlay "From Cluster Chaos to Clarity; My Wild Ride Upgrading Azure AKS", with the Kubernetes logo, the Microsoft Azure AKS logo, and the Notch8 logo.

Ever had one of those projects where you confidently say "should be done by lunch" only to find yourself three days later, surrounded by empty coffee cups and questioning your life choices?

Welcome to my recent Azure AKS upgrade adventure – a journey that started as routine maintenance and evolved into the kind of war story that makes for great conference talks (and even better client case studies).


Plot Twist: When AWS Muscle Memory Meets Azure Reality


Here's the thing about being an AWS-native engineer stepping into Azure: it's like being fluent in Spanish and thinking Portuguese will be a breeze. Sure, there are similarities, but those subtle differences? They'll humble you real quick.


Walking into this AKS upgrade, I had that classic developer confidence: "Kubernetes is Kubernetes, right? How different can Azure be?"


(Narrator's voice: It was different enough.)


Chapter 1: The Great Service Principal Conspiracy

Azure welcomed me with this delightful greeting:

Your service principal has expired or is invalid.

Nothing quite like starting your "routine upgrade" with expired credentials. It's the cloud equivalent of showing up to present at a big meeting only to discover your laptop won't turn on.

For my AWS friends reading this: imagine if your IAM roles just... decided to ghost you mid-deployment. That's basically what happened here.


The solution involved updating the service principal secret and convincing AKS to actually use the new credentials:

az aks update-credentials \
  -g nonprod \
  -n nonprod \
  --reset-service-principal \
  --service-principal <service-principal-uuid> \
  --client-secret '<new-token>'

Pro tip learned the hard way: Every AKS node has its own /etc/kubernetes/azure.json file where old credentials love to hang out like stubborn house guests. Miss those, and they'll sabotage your upgrade faster than you can say "401 Unauthorized."


Chapter 2: Rancher vs. Reality (Spoiler: Reality Wins)

Even after updating credentials through Rancher, nodes were clinging to old secrets like they were family heirlooms. This taught me a valuable lesson about trust in distributed systems: verify everything, assume nothing propagates correctly the first time.


Sometimes the most elegant solution is the most direct one – bypassing the UI and going straight to the CLI to make sure changes actually stick.


Chapter 3: The App Gateway Identity Crisis

Just when I thought we were in the clear, my ingress controller threw its own tantrum:

unable to get specified AppGateway [prod-gateway], check AppGateway identifier
InnerError="azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token

Translation: "I see your new credentials, but I'm emotionally attached to the expired ones."

This required re-binding the App Gateway identity – essentially the cloud equivalent of turning it off and on again, but with more YAML and significantly more stress.


The Victory Lap

After wrestling with expired tokens, stubborn secret propagation, and identity binding issues across multiple environments...


🎉 Both production and non-production clusters upgraded successfully.

More importantly, we now have battle-tested playbooks for handling similar scenarios in the future.


Why This Story Matters

This isn't just another "things went wrong but we fixed them" post. This is about the reality of modern DevOps: the messy, unpredictable, deeply human experience of managing complex systems.


The official documentation rarely captures these edge cases. Azure's upgrade guides don't mention what happens when Rancher and AKS disagree about credential propagation. AWS migration tutorials don't prepare you for the cultural differences between cloud providers.

But here's what I love about our industry: every debugging session makes us sharper. Every unknown we encounter becomes a known for the next engineer facing the same challenge. Every time we ship through the chaos, we're building resilience – for our systems, our teams, and our clients.


The Real Talk

Cloud migrations and upgrades don't have to be white-knuckle experiences. Yes, complexity is inevitable when you're managing distributed systems at scale. But with the right expertise, proper planning, and a team that thrives on solving interesting problems, even the most challenging upgrades become opportunities to build better, more resilient infrastructure.

If your team is facing similar challenges – whether it's AKS upgrades, multi-cloud strategies, or just trying to sleep better knowing your production systems are in good hands – this is exactly the kind of problem we love solving.


Because at the end of the day, your infrastructure challenges shouldn't keep you up at night. That's our job.


Ready to turn your next cloud project from chaos to clarity? Let's chat about how we can help your team ship with confidence.

ree



April Rieger | Senior Software Engineer & Cloud Infrastructure Specialist Turning complex cloud challenges into scalable solutions – one cluster at a time.



 
 
bottom of page