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.
- QuickStart - RabbitMQ and Go
- QuickStart - Azure Functions and Queues
- QuickStart - Azure Functions and Kafka on Openshift 4
There are many ways to deploy KEDA including Helm, Operator Hub and YAML files.
Interested to learn more? Head over to keda.sh.
You can find a FAQ here with some common questions.
You can find several samples for various event sources here.
You can find the latest releases here
You can find Contributing guide here
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://zoom.us/j/150360492
- 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 [email protected]: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.
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 [email protected]: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
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 be KEDA to be fully operational we need to deploy Metrics Server first.
-
Deploy CRDs and KEDA into
keda
namespacekubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml kubectl apply -f deploy/
-
Scale down
keda-operator
Deploymentkubectl scale deployment/keda-operator --replicas=0 -n keda
-
Run the operator locally with the default Kubernetes config file present at
$HOME/.kube/config
and change the operator log level via--zap-level=
if neededoperator-sdk run --local --namespace="" --operator-flags="--zap-level=info"
Note: On older operator-sdk versions you need to use command
up
instead ofrun
.Note: Please run
operator-sdk -h
to see all possible commands and options (eg. for debugging:--enable-delve
)
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:
- Make your change in the code.
- In terminal, create an environment variable
VERSION
and assign it a value for your preference, this tag will be used when creating the operator image that will run KEDA. Note: make sure it doesn't clash with the official tags of KEDA containers in DockerHub. - Still in terminal, run
make build
at the root of the source code. This will also build the docker image for the KEDA operator that you can deploy to your local cluster. This should build 2 docker images:kedacore/keda
andkedacore/keda-metrics-adapter
tagged with the tag you set in step 2 - If you haven't downloaded them before, clone the charts repository:
git clone [email protected]:kedacore/charts.git
- Still in terminal, navigate to the
charts/keda
folder (downloaded in step 4), and run the following command (don't forget to replace the placeholder text in the command):This will use the images built at step 3. Notice the need to override the image pullPolicy tohelm install . --set image.keda=kedacore/keda:$VERSION,image.metricsAdapter=kedacore/keda-metrics-adapter:$VERSION,image.pullPolicy=IfNotPresent
IfNotPresent
in order to use the locally built images and not try to pull the images from remote repo on Docker Hub (and complain about not finding them). - 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
You can change default log levels for both KEDA Operator and Metrics Server. KEDA Operator uses Operator SDK logging mechanism.
To change the logging level, find --zap-level=
argument in Operator Deployment section in deploy/12-operator.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 time format, find --zap-time-encoding=
argument in Operator Deployment section in deploy/12-operator.yaml
file, modify it's value and redeploy.
Allowed values are epoch
, millis
, nano
, or iso8601
Find --v=0
argument in Operator Deployment section in deploy/22-metrics-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"