Table of Contents generated with DocToc
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 have fully operational KEDA we need to deploy Metrics Server first.
- Deploy CRDs and KEDA into
keda
namespacemake 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-log-level=
if neededmake run ARGS="--zap-log-level=debug"
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.
- Build and publish images with your changes,
IMAGE_REPO
should point to your repository,IMAGE_REGISTRY
allows you to use registry of your choice eg. quay.io, default isghcr.io
IMAGE_REGISTRY=docker.io IMAGE_REPO=johndoe make publish
- Deploy KEDA with your custom images.
IMAGE_REGISTRY=docker.io IMAGE_REPO=johndoe make deploy
- Once the KEDA pods are up, check the logs to verify everything running ok, eg:
kubectl logs -l app=keda-operator -n keda -f kubectl logs -l app=keda-metrics-apiserver -n keda -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-log-level=
argument in Operator Deployment section in config/manager/manager.yaml
file,
modify its 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 its value and redeploy.
Allowed values are json
and console
Default value: console
Find --v=0
argument in Operator Deployment section in config/metrics-server/deployment.yaml
file, modify its 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"
Refer to Enabling Memory Profiling on KEDA v2.