Requirements

Kubernetes Compatibility

The supported window of Kubernetes versions with KEDA is known as “N-2” which means that KEDA will provide support for running on N-2 at least.

However, maintainers can decide to extend this by supporting more minor versions based on the required CRDs being used; but there is no guarantee.

As a reference, this compatibility matrix shows supported k8s versions per KEDA version:

Cluster Capacity

The KEDA runtime require the following resources in a production-ready setup:

These are used by default when deploying through YAML.

💡 For more info on CPU and Memory resource units and their meaning, see this link.

Firewall

KEDA requires to be accessible inside the cluster to be able to autoscale.

Here is an overview of the required ports that need to be accessible for KEDA to work:

High Availability

KEDA does not provide full support for high-availability due to upstream limitations.

Here is an overview of all KEDA deployments and the HA notes:

HTTP Timeouts

Some scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.

You can override this default by setting the KEDA_HTTP_DEFAULT_TIMEOUT environment variable on the KEDA operator deployment to your desired timeout in milliseconds.

⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.

HTTP connection disable keep alive

Keep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.

You can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:

- env:
    KEDA_HTTP_DISABLE_KEEP_ALIVE: true

All applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.

HTTP Proxies

Some scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.

- env:
    HTTP_PROXY: http://proxy.server:port
    HTTPS_PROXY: http://proxy.server:port
    NO_PROXY: 10.0.0.0/8

Kubernetes Client Parameters

The Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:

Configure MaxConcurrentReconciles for Controllers

To implement internal controllers KEDA uses the controller-runtime project, that enables configuration of MaxConcurrentReconciles property, ie. the maximum number of concurrent reconciles which can be run for a controller.

KEDA Operator exposes properties for specifying MaxConcurrentReconciles for following controllers/reconcilers:

• ScaledObjectReconciler - responsible for watching and managing ScaledObjects, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.
• ScaledJobReconciler - responsible for watching and managing ScaledJobs and dependent Kubernetes Jobs

KEDA Metrics Server exposes property for specifying MaxConcurrentReconciles for MetricsScaledObjectReconciler, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.

To modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:

Configure Leader Election

Like reconciliation, KEDA also uses the controller-runtime project for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:

• LeaseDuration
• RenewDeadline
• RetryPeriod

To specify values other than their defaults, you can set the following environment variables:

Certificates used by KEDA Metrics Server

By default KEDA Metrics Server uses self-signed certificates while communicating with Kubernetes API Server. It is recommended to provide own (trusted) certificates instead.

Certificates and CA bundle can be referenced in args section in KEDA Metrics Server Deployment:

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

The custom CA bundle should be also referenced in the v1beta1.external.metrics.k8s.io APIService resource (which is created during the installation of KEDA).

You should also make sure that insecureSkipTLSVerify is not set to true.

---
spec:
  service:
    namespace: keda
    name: keda-metrics-apiserver
    port: 443
  group: external.metrics.k8s.io
  version: v1beta1
  caBundle: >-
        YOURCABUNDLE...
  groupPriorityMinimum: 100
  versionPriority: 100

Restrict Secret Access

By default, KEDA requires adding secrets to the cluster role as following:

- apiGroups:
    - ""
  resources:
    - external
    - pods
    - secrets
    - services
  verbs:
    - get
    - list
    - watch

However, this might lead to security risk (especially in production environment) since it will grant permission to read secrets from all namespaces.

To restrict secret access and limited to KEDA namespace, you could add KEDA_RESTRICT_SECRET_ACCESS as environment variable to both KEDA Operator and KEDA Metrics Server:

env:
  - name: KEDA_RESTRICT_SECRET_ACCESS
    value: "true"

This allows you to omit secrets from the cluster role, which will disallow TriggerAuthentication to be used for your triggers if the TriggerAuthentication is using secrets. You can, however, still use ClusterTriggerAuthentication.