Edit

Share via


Breaking changes in Event-driven Autoscaling add-ons 2.15 and 2.14

This article explores the key breaking changes that are introduced in Event-driven Autoscaling (KEDA) add-ons 2.15 and 2.14. It also provides information about how to prepare your Azure Kubernetes Service (AKS) clusters for these updates.

Breaking changes in KEDA 2.15 and 2.14

Your AKS cluster Kubernetes version determines which KEDA version will be installed on your AKS cluster. For AKS clusters that are running Kubernetes version 1.30, KEDA add-on version 2.14 is installed. The upcoming release of Kubernetes 1.32 on Azure will ship together with KEDA add-on version 2.15.

KEDA 2.15

KEDA 2.14

Frequently asked questions

How can I determine whether my cluster is affected?

To determine whether your cluster is affected by the recent KEDA upgrades, follow these steps:

  1. Identify the Kubernetes version of your AKS cluster.

    Clusters that are running Kubernetes versions 1.30 or later will be affected by the KEDA upgrades (2.15 or 2.14). If you're on version 1.29 or earlier, these updates will not affect you. However, if you plan to upgrade your AKS cluster to Kubernetes version 1.30 or 1.31, make sure to review the changes and prepare accordingly before you upgrade.

    To check the cluster version, run the following the Azure CLI command:

    az aks show --resource-group <your-resource-group> --name <your-cluster-name> --query kubernetesVersion
    

    Example of the output:

    "1.30"
    
  2. Review the configurations of KEDA Scalers that are currently deployed in your cluster. Check whether Microsoft Entra pod-managed Identities are used for authentication. The following command displays output only if you're using Pod Identity together with KEDA:

    kubectl get TriggerAuthentication --all-namespaces -o jsonpath='{range .items[?(@.spec.podIdentity.provider=="azure")]}{.metadata.namespace}{"/"}{.metadata.name}{"\n"}{end}'
    

    Example of the output:

    NAME                      PODIDENTITY                 SECRET                 ENV            VAULTADDRESS  
    keda-trigger-auth-azure     yourPodIdentity    azure-secret                                  <URL>
    

What steps can I take to mitigate the issues?

  1. Migrate from Microsoft Entra pod-managed identities to workload identity for authentication. For more information, see Use Microsoft Entra Workload ID with AKS and Migrate from pod managed-identity to workload identity.

  2. Update Scaler Configurations to align with the new configuration requirements:

    • For Azure Data Explorer Scaler, replace metadata.clientSecret with clientSecretFromEnv. For more information about the clientSecretFromEnv definition, see Trigger Specifications.
    • For Azure Blob Scaler and Azure Log Analytics Scaler, move trigger.metadata.metricName to trigger.name.
  3. Test changes in a nonproduction environment. Deploy the updated configurations in a staging or development environment to make sure that they work correctly and don't affect your applications.

  4. Monitor logs and alerts. After you make changes, monitor the cluster logs for any warnings or errors that are related to the new KEDA configuration and behavior.

How can I get support if I have follow-up questions?

If you have questions or need help, create a support request for KEDA add-on.

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.