Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: BUILD.md

<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Table of Contents generated with - - - - - - - <!-- END doctoc generated TOC please keep comment here to allow auto update --> 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 and the [Remote Containers extensions]( https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) Clone the repo and launch code: ```bash 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: ```bash 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 , make sure you have installed the right version. To check the current version used for KEDA check the `RELEASE_VERSION` in file . ```bash 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. ```bash go env GOPROXY GOSUMDB direct off ``` If not set properly you can just run. ```bash 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` namespace ```bash make deploy ``` Scale in `keda-operator` Deployment ```bash kubectl 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 needed ```bash make 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 is `ghcr.io` ```bash IMAGEREGISTRY=docker.io IMAGEREPO=johndoe make publish ``` Deploy KEDA with your custom images. ```bash IMAGEREGISTRY=docker.io IMAGEREPO=johndoe make deploy ``` Once the KEDA pods are up, check the logs to verify everything running ok, eg: ```bash kubectl logs -l app=keda-operator -n keda -f kubectl logs -l app=keda-metrics-apiserver -n keda -f ``` KEDA uses certificates to encrypt any HTTP

Inside the cluster, certificates are mounted from a secret but locally debugging that isn't possible, so the generation of those certificates is required (or KEDA won't start). All components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates. You can generate the certificates (assuming the default path) using `openssl`: ```bash mkdir -p /certs openssl req -newkey rsa:2048 -subj '/CN=localhost' -nodes -keyout /certs/tls.key -x509 -days 3650 -out /certs/tls.crt cp /certs/tls.crt /certs/ca.crt ``` Follow these instructions if you want to debug the KEDA operator using VS Code. Create a `launch.json` file inside the `.vscode/` folder in the repo with the following configuration: ```json { "configurations": [ { "name": "Launch operator", "type": "go", "request": "launch", "mode": "debug", "program": "${workspaceFolder}/cmd/operator/main.go", "env": { "WATCH_NAMESPACE": "", "KEDACLUSTEROBJECT_NAMESPACE": "keda" } } ] } ``` Refer to for more information about debugging with VS Code. Deploy CRDs and KEDA into `keda` namespace ```bash make deploy ``` Scale in `keda-operator` Deployment ```bash kubectl scale deployment/keda-operator --replicas=0 -n keda ``` Set breakpoints in the code as required. Select `Run > Start Debugging` or press `F5` to start debugging. Note: You will be able to manually query metrics to your local version of the KEDA Metrics server. You won't replace the KEDA Metrics server deployed on the Kubernetes cluster. Follow these instructions if you want to debug the KEDA metrics server using VS Code. Create a `launch.json` file inside the `.vscode/` folder in the repo with the following configuration: ```json { "configurations": [ { "name": "Launch metrics-server", "type": "go", "request": "launch", "mode": "auto", "program": "${workspaceFolder}/cmd/adapter/main.go", "env": { "WATCH_NAMESPACE": "", "KEDACLUSTEROBJECT_NAMESPACE": "keda" }, "args": [ "--authentication-kubeconfig=PATHTOYOUR_KUBECONFIG", "--authentication-skip-lookup", "--authorization-kubeconfig=PATHTOYOUR_KUBECONFIG", "--lister-kubeconfig=PATHTOYOUR_KUBECONFIG", "--secure-port=6443", "--v=5" ], } ] } ``` Refer to for more information about debugging with VS Code. Deploy CRDs and KEDA into `keda` namespace ```bash make deploy ``` Set breakpoints in the code as required. Select `Run > Start Debugging` or press `F5` to start debugging. In order to perform queries against the metrics server, you need to use an authenticated user (with enough permissions) or give permissions over external metrics API to `system:anonymous`. To grant access over external metrics API to `system:anonymous`, you only need to deploy this manifest (and remove it once you have finished): ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: grant-anonymous-access-to-external-metrics roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: keda-external-metrics-reader subjects: kind: User name: system:anonymous namespace: default ``` NOTE: This granting allows to any unauthenticated user to do any operation in external metrics API, this is potentially unsecure, and we strongly discourage doing it on production clusters. You can query list metrics executing `curl --insecure https://localhost:6443/apis/external.metrics.k8s.io/v1beta1/` or query a specific metrics value executing `curl --insecure https://localhost:6443/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE/METRIC_NAME` ( but using `curl --insecure https://localhost:6443` instead) If you prefer to use an authenticated user, you can use a user or service account with access over external metrics API adding their token as authorization header in `curl`, ie: `curl -H "Authorization:Bearer TOKEN" --insecure

Follow these instructions if you want to debug the KEDA webhook using VS Code. Create a `launch.json` file inside the `.vscode/` folder in the repo with the following configuration: ```json { "configurations": [ { "name": "Launch webhooks", "type": "go", "request": "launch", "mode": "auto", "program": "${workspaceFolder}/cmd/webhooks/main.go", "env": { "WATCH_NAMESPACE": "", "KEDACLUSTEROBJECT_NAMESPACE": "keda" }, "args": [ "--zap-log-level=debug", "--zap-encoder=console", "--zap-time-encoding=rfc3339" ] }, ] } ``` Refer to for more information about debugging with VS Code. Expose your local instance to internet. If you can't expose it directly, you can use something like using the command `lt --port 9443 --local-https --allow-invalid-cert` after installing the tool. Update the `admissing_webhooks.yaml` in `config/webhooks`, replacing the section (but not committing this change) ```yaml webhooks: admissionReviewVersions: v1 clientConfig: service: name: keda-admission-webhooks namespace: keda path: /validate-keda-sh-v1alpha1-scaledobject ``` with the section: ```yaml webhooks: admissionReviewVersions: v1 clientConfig: url: "https://${YOUR_URL}/validate-keda-sh-v1alpha1-scaledobject" ``` Note: You need to define also the key `caBundle` with the CA bundle encoded in base64. This `caBundle` is the pem file from the CA used to sign the certificate. Remember to disable the `caBundle` inyection to avoid unintended rewrites of your `caBundle` (by KEDA operator or by any other 3rd party) Deploy CRDs and KEDA into `keda` namespace ```bash make deploy ``` Set breakpoints in the code as required. Select `Run > Start Debugging` or press `F5` to start debugging. When you are working with , Visual Studio Code and all the related programs (like `kubectl` or debugging binary) run inside the container. This means that if you are using local clusters like Kind or minikube you won't be able to access them because localhost is the container itself and not the host machine where the cluster is running. To solve this and be able to work with devcontainers and a local cluster, you should follow . You can change default log levels for both KEDA Operator and Metrics Server. KEDA Operator uses mechanism. To change the logging level, find `--zap-log-level=` argument in Operator Deployment section in `config/manager/manager.yaml` file or in Webhooks Deployment section in `config/webhooks/webhooks.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 or in Webhooks Deployment section in `config/webhooks/webhooks.yaml` file, modify its value and redeploy. Allowed values are `json` and `console` Default value: `console` To change the logging time encoding, find `--zap-time-encoding=` argument in Operator Deployment section in `config/manager/manager.yaml` file or in Webhooks Deployment section in `config/webhooks/webhooks.yaml` file, modify its value and redeploy. Allowed values are `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano` Default value: `rfc3339` Note: Example of some of the logging time encoding values and the output: ``` epoch - 1.6533943565181081e+09 iso8601 - 2022-05-24T12:10:19.411Z rfc3339 - 2022-05-24T12:07:40Z rfc3339nano - 2022-05-24T12:10:19.411Z ``` 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 .