+++ title = "Announcing KEDA v2.8 🎉" date = 2022-08-10 author = "Jeff Hollan (KEDA), Tom Kerkhove (KEDA)" aliases = [ "/blog/2.8.0-release" ] +++ 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](https://keda.sh/docs/2.8/scalers/aws-dynamodb-streams/)) - NATS JetStream ([docs](https://keda.sh/docs/2.8/scalers/nats-jetstream/)) 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](https://keda.sh/docs/2.8/concepts/scaling-deployments/#activating-and-scaling-thresholds) ## 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](https://azure.github.io/azure-workload-identity/docs/) 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](https://keda.sh/docs/2.8/concepts/authentication/). ## `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](https://keda.sh/docs/2.8/concepts/scaling-jobs/) and join our [GitHub Discussion](https://github.com/kedacore/keda/discussions/3552) 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](https://github.com/kedacore/keda/releases/tag/v2.8.0). The next KEDA release is scheduled for the first week of November 2022. Thanks to everyone for helping make KEDA better!