This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 92%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESA%3C/text%3E%3C/svg%3E)
I've inherited an AKS 1.24.9 cluster and need to update. Can this be done without rebuilding.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(105.60000000000001, 79%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3END%3C/text%3E%3C/svg%3E)
Hi Seth Abady,
Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.
Upgrading an Azure Kubernetes Service (AKS) cluster from version 1.24.9 to 1.28.13 involves several considerations. When you upgrade a supported AKS cluster, you can't skip Kubernetes minor versions. You must perform all upgrades sequentially by major version number. For example, upgrades between 1.14.x -> 1.15.x or 1.15.x -> 1.16.x are allowed. 1.14.x -> 1.16.x isn't allowed. You can only skip multiple versions when upgrading from an unsupported version back to a supported version. For example, you can perform an upgrade from an unsupported 1.10.x to a supported 1.12.x if available.
It provides a clear explanation of how to upgrade a cluster. Please review it and let me know if you encounter any problems. Upgrade an Azure Kubernetes Service (AKS) cluster
If no upgrades are available, create a new cluster with a supported version of Kubernetes and migrate your workloads from the existing cluster to the new cluster. AKS does not support upgrading a cluster to a newer Kubernetes version when no upgrades are available.
If you have any further queries, do let us know.
Thank you. From within the portal, I'm able to select 2.28.x. My concern is 1 or more deprecated APIs. This is a legacy service from a 3rd party that I'm unable to recreate. I cannot find where these APIs are referenced.
Is it okay to process the upgrade, or do I need to resolve these API references before processing upgrade? My concern is breaking the service by attempting to upgrade, but we need to upgrade to maintain certificate.
apiserver_requested_deprecated_apis{group="autoscaling",removed_release="1.25",resource="horizontalpodautoscalers",subresource="",version="v2beta1"} 1
apiserver_requested_deprecated_apis{group="batch",removed_release="1.25",resource="cronjobs",subresource="",version="v1beta1"} 1
apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="poddisruptionbudgets",subresource="",version="v1beta1"} 1
apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1
Hi @Seth Abady,
Thank you for reaching us again and sharing information.
Yes, resolving deprecated API references before upgrading your AKS cluster is crucial. Upgrading to a newer version can cause issues if your applications still depend on APIs that are no longer supported. To ensure a seamless upgrade, it's essential to eliminate the use of deprecated APIs.
Based on the details you've shared, it's evident that your application is currently relying on deprecated APIs that will be removed in Kubernetes 1.25. Addressing this now will help avoid potential disruptions during the upgrade process.
Migrate to non-deprecated APIs: Update custom integrations and controllers to call the non-deprecated APIs. Change YAML files to reference the non-deprecated APIs.
CronJob-apiVersion: batch/v1
HorizontalPodAutoscaler-apiVersion: autoscaling/v1 or apiVersion: autoscaling/v2
PodDisruptionBudget-apiVersion: policy/v1
PodSecurityPolicy -was deprecated in Kubernetes v1.21 and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both:
If you have any further queries, do let us know.
Hi @Seth Abady,
Did you have a chance to review the solution provided above, and did it help you?
Hi @Seth Abady,If the answer has been helpful, we appreciate hearing from you and would love to help others who may have the same question. Accepting answers helps increase visibility of this question for other members of the Microsoft Q&A community.
@Nikhil Duserla thank you for the information. My original requirement was to update the certificate which we were able to do via the associated listener. Because the cluster houses a legacy application, I'm reluctant to make any changes or upgrade unless absolutely necessary. But thank you for the information, as it definitely answered my original question.