Replies: 1 comment
-
In fact, the longer I look at this, the more I think Azure's constraint of not permitting upgrades to unsupported versions is just outright broken. Azure should be desiring users to run supported versions of AKS, so that they don't have to support broken versions. But by refusing to allow me to upgrade to, e.g., 1.24, Azure is essentially shooting itself in the foot here, and keeping me on a version they don't want to support. While 1.24 is itself unsupported, it is surely less unsupported than 1.23, and better to permit a customer to start taking steps towards getting onto a supported version. But as it stands … it seems like Azure makes updating impossible, in this scenario. |
Beta Was this translation helpful? Give feedback.
-
We have a cluster that's running 1.23. According to MS's AKS docs either 1.26 or 1.27 is the oldest supported version (the docs aren't clear about which). If I attempt to list upgrades for this cluster,
(So presumably 1.26 is no longer supported?)
But according to k8s' Version Skep Policy, Kubernetes must be upgraded between minor versions in sequence, i.e., 1.23 → 1.24 → 1.25 → 1.26 → 1.27.
Does Azure/AKS offer a path forward here? Or are clusters that fall out of the supported version range just effectively disowned by Azure, and running on hopes and prayers? What should one do here?
(And just … I've been gifted this mess / I didn't create this, so don't shoot the messenger, please.)
Beta Was this translation helpful? Give feedback.
All reactions