KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.

KEDA is designed, tested and is supported to be run on any Kubernetes cluster that runs Kubernetes v1.17.0 or above.

It uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these.

💡 Kubernetes v1.16 is supported with KEDA v2.4.0 or below

Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well..

There is no charge for using KEDA itself, we just ask people to become a listed user when possible.

KEDA allows you to use multiple triggers as part of the same ScaledObject or ScaledJob.

By doing this, your autoscaling becomes better:

• All your autoscaling rules are in one place
• You will not have multiple ScaledObject’s or ScaledJob’s interfering with each other

KEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to.

We recommend not to combine using KEDA’s ScaledObject with a Horizontal Pod Autoscaler (HPA) to scale the same workload.

They will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior.

If you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the CPU scaler & Memory scaler scalers instead.

KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box.

We do, however, provide some alternative approaches:

• Use our HTTP add-on scaler which is currently in experimental stage (GitHub)
• Use Prometheus scaler to create scale rule based on metrics around HTTP events
  • Read Anirudh Garg’s blog post to learn more.

Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it’s really up to the HPA (horizontal pod autoscaler) which polls KEDA.

By default you can’t run KEDA with readOnlyRootFilesystem=true because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system. To overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment. To use your certificate, you need to reference it in the container args section, e.g.:

args:
  - '--client-ca-file=/cabundle/service-ca.crt'
  - '--tls-cert-file=/certs/tls.crt'
  - '--tls-private-key-file=/certs/tls.key'

The target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions.

The current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler’s (HPA) scaling algorithm works.

KEDA currently only supports average metrics. This means that the HPA will use the average value of the metric between the total amount of pods.

There are several ways to get involved.

• Pick up an issue to work on. A good place to start might be issues which are marked as Good First Issue or Help Wanted
• We are always looking to add more scalers.
• We are always looking for more samples, documentation, etc.
• Please join us in our weekly standup.

All scalers have their code here.

No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.

No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.

There are a few reasons for this:

• Run functions on-premises (potentially in something like an ‘intelligent edge’ architecture)
• Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)
• Run functions outside of Azure (no vendor lock-in)
• Specific need for more control (GPU enabled compute clusters, policies, etc.)