Multitenant KEDA

Multitenant KEDA lets you run multiple isolated KEDA operators inside a single Kubernetes cluster, each responsible for scaling workloads in its own set of namespaces. A single shared metrics adapter routes HPA requests to the correct operator automatically, with full mTLS isolation between tenants.

Architecture

Multitenant KEDA introduces three components:

1. Tenant KEDA operators - each typically runs in the keda namespace (but can be installed into a different namespace) and watches only its assigned target namespace(s). They are fully independent: separate deployments, separate TLS certificates, separate reconcile loops.

2. Shared metrics adapter - a single keda-operator-metrics-apiserver that the Kubernetes API server calls for external metrics. It routes each HPA’s metric request to the correct tenant operator based on the ScaledObject’s namespace.

3. Kedify agent is responsible for discovering tenant registrations and synchronizing TLS certificates to the metrics adapter.

Request Flow

1. The Kubernetes HPA controller queries external.metrics.k8s.io for external metric values referenced by an HPA associated with workloads in namespace foo
2. The metrics adapter looks up foo in its namespace-to-tenant routing table
3. The adapter forwards the gRPC GetMetrics call to the tenant operator watching foo over mTLS
4. The result is returned to the HPA

If a namespace doesn’t match any tenant, the request goes to the default tenant. This keeps backward compatibility with existing single-tenant setups.

Deployment Modes

The KEDA Helm chart supports three modes via kedify.multitenant.mode:

Mode	keda-operator	Metrics Server	Webhooks	CRDs
"" (disabled)	Standard single-tenant	Standard	Standard	Standard
"default"	Default tenant + multitenant routing	Yes, routes to tenants	Yes	Yes
"tenant"	Tenant operator only	No	No	No

• Default mode installs the full KEDA stack (operator, metrics server, webhooks, CRDs) with the multitenant routing layer enabled in the metrics adapter.
• Tenant mode installs only the operator. The shared singletons (metrics server, webhooks, CRDs) are turned off automatically because the default installation already provides them. The operator name, service account, and TLS secret are derived from the Helm release name, so tenants sharing a namespace don’t collide. Give each tenant a unique release name and point it at its namespace with watchNamespace.

Tenant Discovery and Registration

Setting correct mode configures the Kedify/KEDA helm chart. Under the hood, each tenant KEDA operator registers itself by creating a ConfigMap labeled kedify.io/tenant-registration: "true" as part of the helm release. The registration ConfigMap contains:

Field	Description
name	Tenant identifier (<namespace>/<release-name>)
namespace	Namespace where the operator runs
watchNamespace	Namespace(s) this operator watches for ScaledObjects
address	gRPC address of the operator (e.g. keda-operator-foo.keda.svc.cluster.local:9666)
tlsSecretRef	Name of the Secret containing the operator’s TLS certificates
isDefaultTenant	Whether this is the default (fallback) tenant
operatorDeploymentName	Name of the operator Deployment

The kedify-agent discovers these ConfigMaps, reads TLS certs from each tenant’s Secret, and syncs everything into a single configuration Secret (kedify-multitenancy-config) that the metrics adapter has mounted as a volume.

Operator Sharding

Instead of one operator handling every ScaledObject in the cluster, you shard the work across multiple operators, each watching a subset of namespaces.

You can deploy multiple keda-operators in a single namespace, one keda-operator per namespace, or any combination of both topologies.

mTLS Certificate Management

Each tenant KEDA operator generates its own TLS certificate pair (managed by KEDA’s built-in cert rotation). The kedify-agent reads these certificates and distributes them to the metrics adapter via the shared configuration Secret.

Certificate rotation is handled automatically:

• The agent periodically checks for certificate changes (SHA256 hash comparison, every 60 seconds)
• Updated certificates are synced to the shared configuration Secret
• The metrics adapter detects the Secret change via filesystem watch and reloads TLS credentials without a restart
• TLS 1.3 minimum is enforced on all tenant connections
• Per-tenant authority is used for SNI/server certificate SAN matching

Routing and Isolation

The metrics adapter maintains a routing table that maps each watched namespace to its tenant’s gRPC client. The routing semantics are:

1. Fast path - direct namespace-to-client map lookup (O(1))
2. Default tenant fallback - if a namespace doesn’t match any tenant, the request goes to the tenant installed with kedify.multitenant.mode=default
3. Error - if no tenants are configured, the request fails

Each tenant operator only sees ScaledObjects in its own namespace. The mTLS certificates are unique per tenant, so even the gRPC transport is isolated.

Prometheus Metrics

The metrics adapter exposes the following Prometheus metrics for monitoring multitenant routing:

Metric	Type	Description
kedify_metrics_adapter_tenant_requests_total	Counter	Total metric requests per tenant
kedify_metrics_adapter_tenant_route_fallback_total	Counter	Requests that fell back to the default tenant
kedify_metrics_adapter_tenant_route_errors_total	Counter	Routing errors (labeled by tenant, cause)
kedify_metrics_adapter_tenant_connection_ready	Gauge	Live tenant gRPC connection state (1=ready, 0=not). Present for every tenant, updated on connection changes regardless of traffic.
kedify_metrics_adapter_tenant_routed_connection_ready	Gauge	Connection readiness observed when routing a request; only present after a tenant has served at least one scaling request.

Kubernetes Events

The metrics adapter emits events on its own Pod:

Type	Reason	Description
Normal	KedifyTenantConnectionReady	gRPC connection to a tenant is established
Warning	KedifyTenantConnectionNotReady	gRPC connection to a tenant failed

Getting Started

Prerequisites

• A Kubernetes cluster
• Helm 3
• A Kedify subscription (helm installation guide)

Add the Kedify chart repository:

helm repo add kedifykeda https://kedify.github.io/charts
helm repo update

1. Install the kedify-agent with multitenancy enabled

helm upgrade --install kedify-agent kedifykeda/kedify-agent \
  --namespace keda --create-namespace \
  --set agent.features.multitenantKEDAEnabled=true \
  --set agent.orgId="<your-org-id>" \
  --set agent.apiKey="<your-api-key>"

The agent watches for tenant registration ConfigMaps and syncs TLS certificates to the metrics adapter.

2. Install the default KEDA operator in multitenant mode

helm upgrade --install keda kedifykeda/keda --version v2.20.1-4 \
  --namespace keda --create-namespace \
  --set kedify.multitenant.mode=default \
  --set watchNamespace=keda

This installs the full KEDA stack with the multitenant routing layer enabled. watchNamespace=keda scopes this operator to the keda namespace. Namespaces not matched by any tenant still fall back to this default tenant for routing. To also reconcile ScaledObjects in unassigned namespaces, omit watchNamespace to watch cluster-wide.

3. Deploy tenant operators

For each tenant, install a KEDA operator in tenant mode pointed at its namespace. Tenant mode turns off the shared singletons (CRDs, metrics server, webhooks) automatically, and the operator/service-account/certificate names are derived from the release name, so a minimal install is all you need:

helm upgrade --install foo kedifykeda/keda --version v2.20.1-4 \
  --namespace keda \
  --set kedify.multitenant.mode=tenant \
  --set watchNamespace=foo

Repeat for each tenant with a unique release name and watchNamespace.

4. Create ScaledObjects

Create ScaledObjects in tenant namespaces as usual; they’re picked up by the correct operator automatically.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-scaledobject
  namespace: foo
spec:
  scaleTargetRef:
    name: my-deployment
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        query: sum(rate(http_requests_total{namespace="foo"}[2m]))
        threshold: "100"

Helm Values Reference

KEDA Chart (kedifykeda/keda)

Value	Default	Description
kedify.multitenant.mode	""	Deployment mode: "" (disabled), "default", or "tenant"
watchNamespace	""	Namespace(s) this operator watches (empty = cluster-wide)
kedify.multitenant.agentNamespace	keda	Namespace where kedify-agent runs
kedify.multitenant.agentServiceAccount	kedify-agent	ServiceAccount of kedify-agent

In tenant mode the chart turns off the shared singletons (metricsServer, webhooks, crds) and derives the operator, service account, and certificate names from the release name automatically, so those values don’t need to be set.

Kedify Agent Chart (kedifykeda/kedify-agent)

Value	Default	Description
agent.features.multitenantKEDAEnabled	false	Enable multitenant KEDA support

Status and Troubleshooting

The kedify-agent reports multitenant status in the KedifyConfiguration custom resource:

kubectl get kedifyconfiguration -n keda -o yaml

Check status.discoveredTenants[] for per-tenant health:

Field	Description
operatorReady	Whether the tenant operator is running
tlsCertReady	Whether the TLS certificate Secret is available
configSynced	Whether the tenant config has been synced to the metrics adapter
message	Human-readable status message

To check the metrics adapter’s tenant connections:

# Check adapter logs for tenant routing events
kubectl logs -n keda deploy/keda-operator-metrics-apiserver | grep -i tenant

# Check Kubernetes events for connection state
kubectl get events -n keda --field-selector reason=KedifyTenantConnectionReady
kubectl get events -n keda --field-selector reason=KedifyTenantConnectionNotReady