Tried using aws-ia/eks-blueprints-addon/aws but that is confusing and adds extra complexity

I'd love to hear more about what was confusing or complex

@bryantbiggs I have no issue with using aws-ia/eks-blueprints-addon/aws but I would belive keda is quite a common use case and keda_enabled=true that was available in the previouse version would be much faster than

module "eks_blueprints_addon" {
  source = "aws-ia/eks-blueprints-addon/aws"

  chart         = "keda"
  chart_version = "1.4.2"
  repository    = "https://kedacore.github.io/charts"
  description   = "Keda helm Chart deployment"
  namespace     = "keda"
}

You can still deploy KEDA with this module:

module "eks_blueprints_addons" {
  source = "aws-ia/eks-blueprints-addons/aws"

  cluster_name      = module.eks.cluster_name
  cluster_endpoint  = module.eks.cluster_endpoint
  cluster_version   = module.eks.cluster_version
  oidc_provider_arn = module.eks.oidc_provider_arn

  ... # Truncated for brevity 

  # Pass in any number of Helm charts to be created for those that are not natively supported
  helm_releases = {
    keda = {
      chart             = "keda"
      chart_version     = "1.4.2"
      repository        = "https://kedacore.github.io/charts"
      description       = "Keda helm Chart deployment"
      namespace         = "keda"
      create_namespace  = true
    }
  }

  tags = local.tags
}

You can still deploy KEDA with this module:

module "eks_blueprints_addons" {
  source = "aws-ia/eks-blueprints-addons/aws"

  cluster_name      = module.eks.cluster_name
  cluster_endpoint  = module.eks.cluster_endpoint
  cluster_version   = module.eks.cluster_version
  oidc_provider_arn = module.eks.oidc_provider_arn

  ... # Truncated for brevity 

  # Pass in any number of Helm charts to be created for those that are not natively supported
  helm_releases = {
    keda = {
      chart             = "keda"
      chart_version     = "1.4.2"
      repository        = "https://kedacore.github.io/charts"
      description       = "Keda helm Chart deployment"
      namespace         = "keda"
      create_namespace  = true
    }
  }

  tags = local.tags
}

I agree this can be done this way, but I thought the use case for EKS Blueprints Addons is providing a simple way of managing addons commonly used.

@lordz-md I second support for KEDA as a "native" add-on. For a functional KEDA controller there's more than just installing the helm chart. In order to e.g use the Cloudwatch scaler (or the SQS scaler, or the DynamoDB scaler etc etc) a whole bunch of IAM policies + IRSA mappings needs to be configured for it, which seems to be right in the realm of this module.

Forgot to mention, can someone re-open this issue? 🙏

Forgot to mention, can someone re-open this issue? 🙏

Re-oppened.

@blakepettersson, if you are ok, I can add your arguments to the issue description

@lordz-md feel free to do so! I could look into a potential implementation if it's something @bryantbiggs / @csantanapr would be interested in.

we will discuss it within the team and report back on whether KEDA will be adopted natively here or not. thank you!

Any movement on this one? This would be a much appreciated addition.

at this time, we do not plan on adding KEDA directly into this project - however, users can still use this project to deploy KEDA as shown here #245 (comment)

Something which may be of interest is the addition of docs for what will be the new and improved aws auth in KEDA in kedacore/keda-docs#1251

Hey!
Sorry for the late response, I have just found this.
@bryantbiggs , I'd like to ask for a reconsideration of this issue, taking into account that KEDA is suggested as replacement of deprecated k8s-cloudwatch-adapter as you can check in their readme (and it's not something recent, it happened 2 years ago). It's quite weird that another official AWS repository suggests KEDA as the replacement of it, but here it's not supported as first class add-on.

Installing KEDA "as it is" is quite easy because helm just works, but for enabling features like IRSA Role assumption you need to create all boring stuff (role, relations, oidc provider) and this module is already creating them for other workloads. I'd suggest including KEDA as add-on and creating at least a role for it, federated with given OIDC for allowing IRSA Role assumption out-of-the-box.

If reconsider this and accept KEDA as add-on, I'm willing to open a PR adding it

Hey Guys

I appreciate if we could open this issue again.

KEDA provides event-driven autoscaling for Kubernetes workloads, supporting a wide range of scalers like AWS SQS, CloudWatch, and DynamoDB. This integration offers significant benefits:

• Efficient Resource Utilization: Automatically scales workloads based on demand, optimizing resource usage and costs.
• Enhanced Performance: Ensures applications respond quickly to varying loads by dynamically adjusting the number of pods.
• Broad Compatibility: Supports multiple event sources, making it versatile for different applications and use cases.

Implementation Details
To facilitate the adoption of KEDA, I have added a simple configuration to enable it within the EKS Blueprints Addons:

enable_keda = true

This configuration ensures KEDA's installation, including all the necessary (just helm chart installtion).

Pull Request
I have already created a PR for this implementation. You can review it here: PR-398

I believe this addition will significantly enhance the repository's functionality and provide great value to the users.

Thank you for considering this proposal.