#39 - AKS LTS for Kubernetes
Hey there! It’s Platform Weekly, the newsletter that makes platform engineering as fun as a weekend in Vegas. What happens here, stays here. Let’s get bakin’
Want more Platform Engineering and DevOps news, analysis, and resources? Consider signing up for a newsletter from our friends over at The New Stack. They have daily and weekly newsletter options to keep devs, engineers, and the cloud native community in-the-know.
Link??
AKS LTS for Kubernetes
Fawad Khaliq, Founder and CTO at Chkk
AKS launched a Long Term Support (LTS) train for its k8s releases. This is splendid and I urge EKS and GKE to follow suit. AKS also launched Cluster Auto-Upgrades, similar to GKE Autopilot. This will definitely help with some of the k8s upgrade pains that I highlighted in my last blog.
Since no good deed should go unpunished, let me also enumerate a few things that won’t be fixed with LTS support and auto-upgrades.
领英推荐
You (SRE/DevOps teams) still own the layers on top
LTS and auto-upgrades will only focus on nodes, control planes, and managed services from each cloud. From the cloud substrate, your add ons (load balancer, DNS, monitoring, etc,) are the same as any other app… but you know they aren’t. KubeCon was rife with stories on how teams have tried and failed at auto-upgrading these components. (I’ll share some of these stories in a follow-up blog)
Upgrade workflows contain business logic
Each upgrade–even inside the same company–is different from the next, and not just because you are going from dev > staging > prod route. You need to understand applications and their business constraints before you can bump an add on or an application version, let alone upgrade the entire cluster. Customers have told me firsthand about hacks they have built to stop Autopilot upgrades, as it’s treating everything inside a cluster as cattle, which is never true.
LTS will make k8s stacks more brittle
Regular upgrades, despite being super painful, have the upside of pulling in new patches (security fixes, features, performance optimizations, etc.) which will happen at a much slower cadence in LTS trains.
TL;DR: It’s great to see this is happening (thanks AKS!) but the upgrade pain is here to stay for the foreseeable future. Managed add ons from cloud providers will help here but there won’t be enough of those in the short-/medium-term. The only single owner responsible for making sure all the layers (cloud substrate, clusters, add-ons, applications) work seamlessly is you (SRE/DevOps teams). I’d love to hear about your experiences with auto-upgrades and how you’re thinking about operationalizing LTS releases.
Quick Bites
?? Not only can Internal Developer Platforms improve DevEx, they also have measurable benefits for the businesses that invest in them. This article is a must-read for anyone who wants to make the business case for their platform.
?? Speaking of making the business case for your platform, an oldie but a goodie. The first step to successfully building your platform is building it together.
?? The folks at Cloudknit shared their platform engineering challenges and solutions.
?? This DevOps engineer believes every DevOps engineer needs ChatGPT in their toolkit