Cluster Latest

Guidance & requirements for running KEDA in your cluster

Requirements

Kubernetes

KEDA is designed, tested and supported to be run on any Kubernetes cluster that runs Kubernetes v1.17.0 or above.

Cluster Capacity

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

DeploymentCPUMemory
Metrics ServerLimit: 1, Request: 100mLimit: 1000Mi, Request: 100Mi
OperatorLimit: 1, Request: 100mLimit: 1000Mi, Request: 100Mi

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:

PortWhy?Remarks
443Used by Kubernetes API server to get metricsRequired for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud.
6443Used by Kubernetes API server to get metricsOnly required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication

High Availability

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

Here is an overview of all KEDA deployments and the supported replicas:

DeploymentSupport ReplicasReasoning
Metrics Server1Limitation in k8s custom metrics server
Operator2While you can run more replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.

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 to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you’d use this command to set to 1 second:

export KEDA_HTTP_DEFAULT_TIMEOUT=1000

And on Windows Powershell, you’d use this command:

$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000

All applicable scalers will use this timeout. Setting a per-scaler timeout 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 Metrics Adapter can be adjusted by passing the following command-line flags to the binary:

Adapter FlagClient Config SettingDefault ValueDescription
kube-api-qpscfg.QPS20.0Set the QPS rate for throttling requests sent to the apiserver
kube-api-burstcfg.Burst30Set the burst for throttling requests sent to the apiserver

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:

Environment variable nameDeploymentDefault ValueAffected reconciler
KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILESOperator5ScaledObjectReconciler
KEDA_SCALEDJOB_CTRL_MAX_RECONCILESOperator1ScaledJobReconciler
KEDA_METRICS_CTRL_MAX_RECONCILESMetrics Server1MetricsScaledObjectReconciler

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:

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

Environment variable nameDeploymentManager Property
KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATIONOperatorLeaseDuration
KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINEOperatorRenewDeadline
KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIODOperatorRetryPeriod
KEDA_METRICS_LEADER_ELECTION_LEASE_DURATIONMetrics ServerLeaseDuration
KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINEMetrics ServerRenewDeadline
KEDA_METRICS_LEADER_ELECTION_RETRY_PERIODMetrics ServerRetryPeriod