We recently completed our most recent release: 2.8.0 🎉!

Here are some highlights:

• Introduction of new AWS DynomoDB Streams & NATS JetStream scalers.
• Introduction of new Azure AD Workload Identity authentication provider.
• Support for specifying minReplicaCount in ScaledJob.
• Support to customize the HPA name.
• Support for permission segregation when using Azure AD Pod / Workload Identity
• Additional features to various scalers such as AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, Prometheus

Here are the new deprecation(s) as of this release:

• rolloutStrategy in ScaledJob is deprecated in favor of rollout.strategy

Let’s have a closer look.

New & Improved Scalers

KEDA now has 50+ built-in scalers, giving you instant access to provide event driven scale across a variety of sources. New with this release are:

• AWS DynamoDB Streams (docs)
• NATS JetStream (docs)

In addition to new scalers, various new features and improvements were added to AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, and Prometheus scalers.

Activation and Scaling Thresholds

Previously in KEDA, when scaling from 0 to 1, KEDA would “activate” (scale to 1) a resource when any activity happened on that event source. For example, if using a queue, a single message on the queue would trigger activation and scale.

As of this release, we now allow you to set an activationThreshold for many scalers which is the metric that must be hit before scaling to 1.

This would allow you to delay scaling up to 1 until n number of messages were unprocessed. This pairs with other thresholds and target values for scaling from 1 to n instances, where the HPA will scale out to n instances based on the current event metric and the defined threshold values.

Details on thresholds and the new activation thresholds can be found in the KEDA concept docs

Introducing support for Azure AD Workload Identity & identity segregation

One critical piece of functionality in KEDA is the ability to authenticate with different event sources. The TriggerAuthentication CRD allows you to define secure secrets and identities to use within your scaled objects and jobs.

As of v2.8.0, you can now use Azure AD Workload Identity which is supported by using azure-workload as a valid pod identity provider.

We want to strive to be as secure as we can and reduce the risk of breach by allowing end-users to use least-privilege principle. This is crucial because KEDA is installed once and available to the whole Kubernetes cluster. However, identities used for Azure AD Pod Identity and Azure AD Workload Identity providers are applied on KEDA itself which means it can be used by all applications.

That is why we are introducing segregation of permissions within KEDA and its used identity/identities.

This means you don’t have to grant the KEDA pod too many permissions to too many sources, and can now specify an identityId in your TriggerAuthentication allowing to define the identity to use which has more scoped permissions for specific triggers.

More details can be found in the KEDA Authentication documentation.

rolloutStrategy in ScaledJob is deprecated in favor of rollout.strategy

As of this release, rolloutStrategy in ScaledJob is deprecated in favor of rollout.strategy and ask all end-users to migrate to rollout.strategy instead.

This change has been introduced so that end-users have more control over how rollouts are performed and have introduced new capabilities such as rollout.propagationPolicy to compliment this.

End-users who are still using rolloutStrategy will not be impacted, until it will be removed in KEDA 3.x.

Learn more in our new documentation and join our GitHub Discussion if you have questions/problems migrating.

Simplified end-to-end testing experience for contributors

We’ve added some new features to our end to end testing and PR process. The test framework used to coordinate end to end tests was moved from TypeScript to Go, so contributors can stick within a single language for the codebase. We also improved the Pull Request process so that all PRs will be blocked until e2e tests pass or until a label ok-to-merge is added, and created a new team keda-e2e-test-executors who can now trigger end to end tests to run.

And more…

This is just some of the highlights for the latest release. You can find the full release notes can be found here.

The next KEDA release is scheduled for the first week of November 2022.

Thanks to everyone for helping make KEDA better!