This branch contains unstable KEDA v2.0.0-alpha1, currently under development

How can I try KEDA v2 alpha version?

Make sure to remove previous KEDA (including CRD) from the cluster. Switch to the v2 branch and deploy yaml files:

   git fetch --all
   git checkout v2
   make deploy

Kubernetes-based Event Driven Autoscaling

KEDA allows for fine-grained autoscaling (including to/from zero) for event driven Kubernetes workloads. KEDA serves as a Kubernetes Metrics Server and allows users to define autoscaling rules using a dedicated Kubernetes custom resource definition.

KEDA can run on both the cloud and the edge, integrates natively with Kubernetes components such as the Horizontal Pod Autoscaler, and has no external dependencies.

We are a Cloud Native Computing Foundation (CNCF) sandbox project.

Table of contents

• Getting started
• Deploying KEDA
• Documentation
• FAQ
• Samples
• Releases
• Contributing
• Community
• Building: Quick start with Visual Studio Code Remote - Containers
• Building: Locally directly
• Deploying: Custom KEDA locally outside cluster
• Deploying: Custom KEDA as an image
• Setting log levels

Getting started

• QuickStart - RabbitMQ and Go
• QuickStart - Azure Functions and Queues
• QuickStart - Azure Functions and Kafka on Openshift 4
• QuickStart - Azure Storage Queue with ScaledJob

Deploying KEDA

There are many ways to deploy KEDA including Helm, Operator Hub and YAML files.

Documentation

Interested to learn more? Head over to keda.sh.

FAQ

You can find a FAQ here with some common questions.

Samples

You can find several samples for various event sources here.

Releases

You can find the latest releases here

Contributing

You can find Contributing guide here

Community

If interested in contributing or participating in the direction of KEDA, you can join our community meetings.

• Meeting time: Bi-weekly Thurs 16:00 UTC (does follow US daylight savings). (Subscribe to Google Agenda | Convert to your timezone)
• Zoom link: https://us02web.zoom.us/j/150360492?pwd=eUVtQzBPMzFoQUR2K1dqUWhENjJJdz09 (Password: keda)
• Meeting agenda: https://hackmd.io/s/r127ErYiN

Just want to learn or chat about KEDA? Feel free to join the conversation in #KEDA on the Kubernetes Slack!

Building: Quick start with Visual Studio Code Remote - Containers

This helps you pull and build quickly - dev containers launch the project inside a container with all the tooling required for a consistent and seamless developer experience.

This means you don't have to install and configure your dev environment as the container handles this for you.

To get started install VSCode and the Remote Containers extensions

Clone the repo and launch code:

git clone git@github.com:kedacore/keda.git
cd keda
code .

Once VSCode launches run CTRL+SHIFT+P -> Remote-Containers: Reopen in container and then use the integrated terminal to run:

make build

Note: The first time you run the container it will take some time to build and install the tooling. The image will be cached so this is only required the first time.

Building: Locally directly

This project is using Operator SDK framework, make sure you have installed the right version. To check the current version used for KEDA check the RELEASE_VERSION in file tools/build-tools.Dockerfile.

git clone git@github.com:kedacore/keda.git
cd keda
make build

If the build process fails due to some "checksum mismatch" errors, make sure that GOPROXY and GOSUMDB environment variables are set properly. With Go installation on Fedora, for example, it could happen they are wrong.

go env GOPROXY GOSUMDB
direct
off

If not set properly you can just run.

go env -w GOPROXY=https://proxy.golang.org,direct GOSUMDB=sum.golang.org

Deploying: Custom KEDA locally outside cluster

The Operator SDK framework allows you to run the operator/controller locally outside the cluster without a need of building an image. This should help during development/debugging of KEDA Operator or Scalers.

Note: This approach works only on Linux or macOS.

To have fully operational KEDA we need to deploy Metrics Server first.

1. Deploy CRDs and KEDA into keda namespace

   make deploy

2. Scale down keda-operator Deployment

   kubectl scale deployment/keda-operator --replicas=0 -n keda

3. Run the operator locally with the default Kubernetes config file present at $HOME/.kube/config and change the operator log level via --zap-log-level= if needed

   make run ARGS="--zap-log-level=debug"

Deploying: Custom KEDA as an image

If you want to change KEDA's behaviour, or if you have created a new scaler (more docs on this to come) and you want to deploy it as part of KEDA. Do the following:

1. Make your change in the code.
2. Build and publish on Docker Hub images with your changes, IMAGE_REPO should point to your repository (specifying IMAGE_REGISTRY as well allows you to use registry of your choice eg. quay.io).

   IMAGE_REPO=johndoe make publish

3. Deploy KEDA with your custom images.

   IMAGE_REPO=johndoe make deploy

4. Once the keda pods are up, check the logs to verify everything running ok, eg:

   kubectl get pods --no-headers -n keda | awk '{print $1}' | grep keda-operator | xargs kubectl -n keda logs -f
   
   kubectl get pods --no-headers -n keda | awk '{print $1}' | grep keda-metrics-apiserver | xargs kubectl -n keda logs -f

Setting log levels

You can change default log levels for both KEDA Operator and Metrics Server. KEDA Operator uses Operator SDK logging mechanism.

KEDA Operator logging

To change the logging level, find --zap-log-level= argument in Operator Deployment section in config/manager/manager.yaml file, modify it's value and redeploy.

Allowed values are debug, info, error, or an integer value greater than 0, specified as string

Default value: info

To change the logging format, find --zap-encoder= argument in Operator Deployment section in config/manager/manager.yaml file, modify it's value and redeploy.

Allowed values are json and console

Default value: console

Metrics Server logging

Find --v=0 argument in Operator Deployment section in config/metrics-server/deployment.yaml file, modify it's value and redeploy.

Allowed values are "0" for info, "4" for debug, or an integer value greater than 0, specified as string

Default value: "0"